[Opgelost] Noodzakelijke voorbereidingen voor uitbreiding SHR 5 -> 8 WD RED's?

[m4v3r1ck]

1. Ik ben bang dat ik toch ook een stapje zelf heb gemist en dat is de snelheid VOOR het uitvoeren van jouw commando's in Terminal te checken, wel heb ik in deze post de snelheid NA de commando's gepost. Deze k(z)akken steeds verder in.

2. Kan ik jouw tweak ook doen bij de maandelijkse pariteitscontrole, is daar een script voor in Taakplanner?

 

[Birdy]

Kan ik jouw tweak ook doen bij de maandelijkse pariteitscontrole, is daar een script voor in Taakplanner?

Ehhhh.....nee, wel een goed idee.....zou dat kunnen maken en testen, wanneer ik daar tijd voor heb

[m4v3r1ck]

Dat noem ik een geweldige inkopper @Birdy !

Daar zouden wellicht meer mede-synologen iets aan kunnen hebben! Bedankt alvast voor het maken/testen van jouw script!

[Ben(V)]

De reden dat die settings zo staan is natuurlijk wel dat met de defaults de rest van je systeem niet volkomen plat gegooid wordt als je met zo'n actie bezig bent.
Dat is in je huidige situatie natuurlijk geen punt, maar de vraag is of je dat ook zo wilt hebben als hij met z'n maandelijkse scrub bezig is.

[Birdy]

Dat is wel een punt als de NAS 24/7 draait en gebruikt moet kunnen worden, zonder hier last van te hebben.
Daar kan @m4v3r1ck alleen iets over zeggen.

[m4v3r1ck]

De reden dat die settings zo staan is natuurlijk wel dat met de defaults de rest van je systeem niet volkomen plat gegooid wordt als je met zo'n actie bezig bent.

Een heel goed punt Ben! Inderdaad staat mijn NAS nu geheel in dienst van de SHR-Uitbreiding op dit moment. Ik maak er alleen nog maar kleine incremental - macOS en Windows 7/10 - back-ups op.

Dat is in je huidige situatie natuurlijk geen punt, maar de vraag is of je dat ook zo wilt hebben als hij met z'n maandelijkse scrub bezig is.

Ik zou heel graag deze tweak van Birdy willen testen als mijn NAS in bedrijf is, met name is van belang - cruciaal - hoe mijn Plex Server zich standhoud tijdens de maandelijkse pariteitscontrole obv een nieuw script in TaakPlanner!

Heb alvast een heel fijn weekend!

[Hofstede]

Ik heb nog een veel betere optie: Die maandelijkse scrubbing gewoon niet uitvoeren. 

Maar goed, de discussie of die wel of niet zinvol is kent net zoveel voor als tegenstanders.

[m4v3r1ck]

En ineens heb ik een speedBUMP! te pakken, alleen heb ik daar natuurlijk geen - heb niets veranderd - enkele logische verklaring voor:

:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdh5[7] sdg5[6] sdf5[5] sda5[0] sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]
      [========>............]  reshape = 41.4% (1211630336/2925531648) finish=7290.5min speed=3917K/sec
      bitmap: 0/22 pages [0KB], 65536KB chunk

md1 : active raid1 sdh2[6] sdg2[7] sdf2[5] sda2[0] sdb2[1] sdc2[2] sdd2[3] sde2[4]
      2097088 blocks [8/8] [UUUUUUUU]
     
md0 : active raid1 sdh1[6] sdg1[7] sdf1[5] sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4]
      2490176 blocks [8/8] [UUUUUUUU]
     
unused devices: <none>

:~# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdh5[7] sdg5[6] sdf5[5] sda5[0] sde5[4] sdd5[3] sdc5[2] sdb5[1]
      11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]
      [=========>...........]  reshape = 47.9% (1403190820/2925531648) finish=3535.4min speed=7176K/sec
      bitmap: 0/22 pages [0KB], 65536KB chunk

md1 : active raid1 sdh2[6] sdg2[7] sdf2[5] sda2[0] sdb2[1] sdc2[2] sdd2[3] sde2[4]
      2097088 blocks [8/8] [UUUUUUUU]
     
md0 : active raid1 sdh1[6] sdg1[7] sdf1[5] sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4]
      2490176 blocks [8/8] [UUUUUUUU]
     
unused devices: <none>

Iemand? Want ik heb zoals aangegeven, pas nog een paar incremental back-ups gedraaid... 

[m4v3r1ck]

Ik heb nog een veel betere optie: Die maandelijkse scrubbing gewoon niet uitvoeren. 

Maar goed, de discussie of die wel of niet zinvol is kent net zoveel voor als tegenstanders.

Voor mij is Synology zelf - waarom anders deze prangende vraag elke maand - het allerbeste argument om het wel te doen, maar daar gaat het hier in dit topic natuurlijk niet om. Voorlopig zitten mijn originele WD RED's van 21-02-2013 er ook nog in: vb. 5.0 = slot#5 disk#0 , als ik deze moet vervangen wordt het 5.1 = slot#5 disk#1. In de oude tijd - slechte HDD's - had ik wel eens een versie 4.7

De tijd tikt door en dus tippen we in 2018 de 5 jaar aan. Mooie ROI lijkt me, ja toch?



Ik zou graag het script van @Birdy willen proberen, want een snelheidsverhoging kan toch hardwarematig geen enkele kwaad?

Hoe dan ook, ik ben nu even bij met de auto-speedbump tijdens mijn SHR-Uitbreiding op mijn NAS.



Ik hoop dat de uitbreiding net zolang meegaat.

[m4v3r1ck]

Mijn SHR-Uitbreiding is nog steeds overuren aan het draaien:



... dus heb ik gelukkig natuurlijk altijd mijn auto-updates UIT staan:



 

[Birdy]

Kan ik jouw tweak ook doen bij de maandelijkse pariteitscontrole, is daar een script voor in Taakplanner?

Ehhhh.....nee, wel een goed idee.....zou dat kunnen maken en testen, wanneer ik daar tijd voor heb

Nou ik heb dus een scriptje gemaakt, die nog niet helemaal af is, maar wel een eerste test gedaan.

Heb eerst op m'n DS411Slim een SHR/RAID5 volume gemaakt.
Hierbij werd dus ook een pariteits-check op uitgevoerd.
De snelheid zat tussen de 13000 en 15000 K/sec.
De check werd goed afgesloten.

Heb daarna m'n scrub script getest, de snelheid liep tussen de 26500 en 31500 K/sec.
Dat was een verbetering die ik wel had verwacht echter, kreeg toen wel problemen met HD3 welke, tot nu toe, nooit problemen heeft gehad.
Na afloop dus gekeken en zie dat HD2 nu 41 bad sectoren heeft gekregen terwijl de 1e (standaard) pariteits-check (vlak daarvoor dus), HD3 nog 0 bad sectoren had, ook kreeg ik meldingen van IO/Errors en Partitie Mislukt op HD3 nadat de scub was beindigd.
Na een kortstondige repair, was weer in orde.

Hiermee wil ik aangeven dat, die HD's behoorlijk onder vuur komen te staan door het ophogen van de snelheid tijden scrubbing (resync) op aangepaste hoge snelheden.

Nu kan het toevallig ook zo zijn, dat mijn oude 2.5" HD-tje er niet echt meer tegen kon.
Maar, ik vraag mij wel af, of het zo verstandig is om die tweak te gebuiken bij het scrubben, de HD's worden dan, eigenlijk onnodig, behoorlijk op de proef gesteld.

Ook bij het uitbreiden of repareren zou het ook gebeuren als je b.v. (ik zeg maar wat) 1 nieuwe HD toevoegt of vervangt, waarbij de oudjes daar flink onder lijden.

Kortom, bij scrubbing zou ik het sowieso niet doen en al helemaal niet als dit maandelijks plaats vind.


PS: 4 Jaar geleden (denk ik) heb ik die tweak ook toegepast bij het vervangen van 1 HD echter, toen had ik geen problemen en liep lekker vlotjes maar, ik begin er nu anders over te denken of ik dit nog wel wil, wanneer het weer zover is.
   

[m4v3r1ck]

Bedankt voor je feedback!

Wat is het reset-commando om de snelheid weer naar fabriekswaarde terug te zetten?

Mijn oude WD RED's zijn bijna 5! jaar, dus lijkt het me obv jouw laatste info raadzaam om die uitgevoerde speed-commando's asap te resetten...

Heb een fijne Kerst allemaal!

[Birdy]

sysctl dev.raid.speed_limit_min=10000

sysctl dev.raid.speed_limit_max=200000 (maar die stond standaard al zo, heb ik gezien)

Nog even gekeken naar mijn HD3, deze is al 9 jaar oud

[m4v3r1ck]

Mission Accomplished!



Bedankt allemaal voor het meedenken en -DOEN! 

... ondertussen ben ik al mijn Packages en Services weer aan het herstarten.

Hier word ik blij van! 

[Birdy]

Mooi zo, kun je voorlopig weer vooruit.