mdadm resync hemeltergend traag

[dion_b]

Achtergrond:

Mijn thuisserver/HTPC draait al een paar jaar een RAID1 array van twee 1.5TB WD Green HDDs. Tot een maand ofzo geleden geen probleem. OS draait op aparte HDD. Op gegeven moment werd het systeem - beter gezegd: alles wat met md0 te maken had - zodanig traag dat het onwerkbaar was. Ik had op dat moment geen tijd voor uitgebreide troubleshooting, dus gereboot. Bij reboot melding dat RAID array degraded was...

Volgende avond wel grondig getest: SMART info gaf aan dat beide weliswaar oud waren, maar geen kritieke problemen. Sterker nog, de drive die eruit gedonderd was (/dev/sdc) zag er iets beter uit dan degene die er nog in zat (/dev/sdb). Alle data was nog op beide drives aanwezig en rechtstreeks reads/writes naar de drives ging goed en snel.

Dus bij gebrek aan duidelijk probleem geprobeerd het array weer te syncen. Dat duurde ruim een week, waarbij snelheid ene keer erg hoog was (tientallen MB/s) maar vaak erg laag (tientallen kB/s). Op dat moment vermoedde ik dat het kwam doordat het fs gemount was en gebruikt werd. Maar... na afloop resync zelfde gedrag: soms (heel soms) even bliksemsnel als voorheen. Brak, erg brak dus.

Wederom diag erop losgelaten, wederom niets kunnen vinden. Na flink wat zoekwerk gevonden dat er mogelijk een UDMA bug in de kernel zou kunnen zitten die dit zou veroorzaken. Op dat moment ben ik er niet verder op ingegaan aangezien ik twee weken werk+prive te druk was (conferentie, huis kopen, dat soort dingen). Bovendien draaide ik een oude Xubuntu (non-LTS) install waarvan de support gestopt was, dus sowieso moest ik de boel grondig onder handen nemen.


Vandaag eindelijk tijd gehad om ermee aan de slag te gaan. De oude HDD die voor OS diende heb ik vervangen door een SSD die ik over had. Bovendien heb ik voor de zekerheid beide SATA kabels naar de 1.5TB drives vervangen. Daar heb ik Mint 17 (gebaseerd op Ubuntu 14.04 LTS) op gezet en de array eraan gehangen. sudo mdadm --assemble --scan vond gelijk de array en begon het te syncen. Met 300-400kB/s snelheid

Op dit tempo duurt het zo'n anderhalve maand voor het werkend is. Nu weet ik dat performance van een resync aanzienlijk verhoogd wordt als je bitmapping aanzet, maar dat kun je niet doen terwijl de boel al aan het syncen is - en dat is hij per definitie als je een 'nieuwe' array assembleert. Dus mdadm --grow --bitmap=internal /dev/md0 geeft terecht een fail omdat een sync bezig is.

Volgende poging om de boel te verhogen:
/proc/sys/dev/raid bevat twee speed limits:
speed_limit_max - wat nu op 200000 staat
speed_limit_max - wat nu op 1000 staat

Nu lees ik op verschillende plekken (bijv hier) dat je simpelweg met een echo die limieten kan wijzigen. Maar zodra ik probeer dit te doen: sudo echo 100000 > /proc/sys/dev/raid/speed_limit_min - krijg ik de melding bash: speed_limit_min: Permission denied
Lijk trouwens niet de enige te zijn, maar heb daar geen reden of oplossing/workaround voor gezien.

Syslog toont geen errors waar ik wat mee kan, dit is output sinds ik de array weer activeerde:

code:

Oct 12 23:23:21 Thalia kernel: [ 3804.266591] md: export_rdev(sdc1)
Oct 12 23:24:10 Thalia kernel: [ 3853.304037] md: md0 stopped.
Oct 12 23:24:10 Thalia kernel: [ 3853.304910] md: bind<sdc1>
Oct 12 23:24:10 Thalia kernel: [ 3853.305102] md: bind<sdb1>
Oct 12 23:24:10 Thalia kernel: [ 3853.308924] md/raid1:md0: not clean -- starting background reconstruction
Oct 12 23:24:10 Thalia kernel: [ 3853.308927] md/raid1:md0: active with 2 out of 2 mirrors
Oct 12 23:24:10 Thalia kernel: [ 3853.308942] md0: detected capacity change from 0 to 1500299255808
Oct 12 23:24:10 Thalia kernel: [ 3853.309088] md: resync of RAID array md0
Oct 12 23:24:10 Thalia kernel: [ 3853.309092] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
Oct 12 23:24:10 Thalia kernel: [ 3853.309093] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for resync.
Oct 12 23:24:10 Thalia kernel: [ 3853.309096] md: using 128k window, over a total of 1465135992k.
Oct 12 23:24:10 Thalia kernel: [ 3853.309098] md: resuming resync of md0 from checkpoint.
Oct 12 23:24:10 Thalia kernel: [ 3853.345872]  md0: unknown partition table

Ondertusen zijn we weer een kwartier verder en is dit de status van de resync:

code:

Personalities : [raid1] 
md0 : active raid1 sdb1[2] sdc1[3]
      1465135992 blocks super 1.2 [2/2] [UU]
      [>....................]  resync =  0.0% (1458688/1465135992) finish=72863.2min speed=334K/sec
      
unused devices: <none>

Voor de goede orde: de SATA controller zit in een Intel H61 chipset, dus volgens lspci: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05), en de drives worden inderdaad in AHCI-modus aangestuurd.

Iemand idee hoe ik dit versneld krijg?

[ Voor 21% gewijzigd door dion_b op 13-10-2014 00:31 ]

[HollowGamer]

Dat commando, wat als je eerst sudo -s doet, om zo 'echt' als root uit te voeren?

Welk filesysteem heb je btw.? En welke kernel versie? Heb je de BIOS al eens gereset?

[CAPSLOCK2000]

dion_b schreef op zondag 12 oktober 2014 @ 23:38:

Nu lees ik op verschillende plekken (bijv hier) dat je simpelweg met een echo die limieten kan wijzigen. Maar zodra ik probeer dit te doen: sudo echo 100000 > /proc/sys/dev/raid/speed_limit_min - krijg ik de melding bash: speed_limit_min: Permission denied
Lijk trouwens niet de enige te zijn, maar heb daar geen reden of oplossing/workaround voor gezien.

Daar kan ik je mee helpen, 'sudo' slaat hier alleen op de 'echo', de output-redirectin ('> /proc/sys/...') draait weer onder je eigen gebruiker. Doe het eens als

sudo bash -c "echo 100000 > /proc/sys/..."

Misschien is het probleem de alignment van je disk. IIRC gebruiken die 1.5T WD Greens 4K blocks en moet je bij die schijven rekening houden met alignment. Anders moet hij bij ieder block dat je contreelt twee blocks van de beide disks inlezen en vervolgens ook weer twee blocks terugschrijven. Dat hakt er aardig in, al vind ik 300K wel heel erg langzaam. Als het al zo is valt dat helaas niet op te lossen zonder te formatteren, dus daar heb jij niks aan.


Je zou nog kunnen kijken of er niet toch stiekem een proces iets met die array probeert te doen. Pauzeer de sync eventueel eerst met

echo "idle" > /sys/block/md0/md/sync_action 

[dion_b]

Ah, dom van me mbt sudo
_{wel opvallend dat het niet duidelijker in de Ubuntu sites stond...}

Min/maxwaardes verhoogd, dat was hem niet, niets veranderd - ook niet gek aangezien de oude min waarde al verre van gehaald werd.

Gechecked mbt alignment, dat was het alvast niet, netjes op sector 1 aligned. En dan nog:
1) 300-400kB/s is stukken lager dan wat je bij misaligned sectors krijgt.
2) dit heeft goed gewerkt, ik heb echt niet stiekem tussendoor opnieuw geformatteerd

Heb vervolgens hdparm erop losgelaten, in eerste instaltie leek het toch iets met /dev/sdc te zijn - sdb deed bijna 6GB/s uit cache en 90MB/s van de disk zelf, terwijl sdc maar 70kB/s deed - maar vervolgens de sync action gepauzeerd en nogmaals getest en zelfde resultaat met sdc gehaald als sdb. Kortom, het is echt de sync zelf die het doet.

Ik kijk verder, maar heb zojuist nog een 1TB externe schijf gevonden. De neiging om alles te backuppen en dan wat destructiever te testen cq de boel from scratch in te stellen wordt steeds sterker...

[HollowGamer]

Wat zijn de systeem specs?
Zelf werkt de mdadm niet snel op mijn low spec nas, heb daarom voor btrfs gekozen als (een soort) raid.

[johnkeates]

En als je puur om te experimenteren eens een RAID1 array bouwt met 1 missing disk, een keer met sdb en een keer met sdc, zit er dan ook geen verschil in? Een sync met een missing device werkt nog steeds dacht ik.

[dion_b]

HollowGamer schreef op maandag 13 oktober 2014 @ 22:54:
Wat zijn de systeem specs?
Zelf werkt de mdadm niet snel op mijn low spec nas, heb daarom voor btrfs gekozen als (een soort) raid.

Core i3 2100, 4GB RAM, OS op een 60GB OCZ Vertex II (Sandforce) SSD. Denk niet dat dat de bottleneck is...

johnkeates schreef op maandag 13 oktober 2014 @ 22:58:
En als je puur om te experimenteren eens een RAID1 array bouwt met 1 missing disk, een keer met sdb en een keer met sdc, zit er dan ook geen verschil in? Een sync met een missing device werkt nog steeds dacht ik.

Hmm, makkelijk om te proberen. Ik ga ermee aan de slag

Edit:
Duurde nog geen seconde per drive

Heb nu beide drives los van elkaar bekeken:
- resync of repair duurt <1sec
- hdparm geeft op zowel physical drive als op array (md0) als op partitie binnen LVM nagenoeg identieke, snelle resultaten
- steekproef toont data veilig aanwezig op beide drive

Alles lijkt prima dus. Maar hang ik ze weer beide eraan, dan krijg ik weer resync met 370kB/s voor m'n kiezen

[ Voor 22% gewijzigd door dion_b op 13-10-2014 23:41 ]

[Hero of Time]

CPU gebruik? Hoe lekker is je Vertex II nog? Die dingen staan tenslotte bekend om zomaar om te vallen. Niet dat het er direct mee te maken moet hebben, maar elke potentiële variabele uitschakelen is beter. Hoe doet een live cd het dan eigenlijk?

[Sprite_tm]

Je wilt misschien iostat -xm 1 draaien tijdens het rebuilden. Als er 1 disk door slijtage of whatever traag is, kan je dat zien doordat de %util de lucht inschiet; de ervaring leert dat het (zeker met WDs) zo nu en dan mogelijk is dat de schijven een flink stuk trager presteren zonder dat ze daadwerkelijk stuk zijn of het aangeven in hun SMART-data.

[u_nix_we_all]

Kijk een in /var/log/messages (of met dmesg) , dit klinkt alsof er een schijf rot is. Ander symptoom is dat de wait-for-IO (bijv met top te zien) vrij hoog staat, deze zou normaal 0% (of daar in de buurt, enkele procenten ofzo) moeten zijn.
Ook hier hebben we dit wel eens met WD schijven gezien BTW.

[dion_b]

Hero of Time schreef op dinsdag 14 oktober 2014 @ 08:30:
CPU gebruik?

Nope, nooit boven 20%, doorgaans ver eronder.

Sowieso, als het aan CPU lag zou de snelheid grillig zijn afhankelijk van andere taken. Maar het is volledig constant ongeacht wat ik doe.

Hoe lekker is je Vertex II nog?

Aangezien er niets veranderde bij uitwisselen HDD <-> SSD lijkt dat me uitgesloten.

Die dingen staan tenslotte bekend om zomaar om te vallen. Niet dat het er direct mee te maken moet hebben, maar elke potentiële variabele uitschakelen is beter. Hoe doet een live cd het dan eigenlijk?

LiveUSB met Mint 17 geeft exact zelfde performance als SSD.

u_nix_we_all schreef op dinsdag 14 oktober 2014 @ 10:51:
Kijk een in /var/log/messages (of met dmesg) , dit klinkt alsof er een schijf rot is. Ander symptoom is dat de wait-for-IO (bijv met top te zien) vrij hoog staat, deze zou normaal 0% (of daar in de buurt, enkele procenten ofzo) moeten zijn.
Ook hier hebben we dit wel eens met WD schijven gezien BTW.

Zal ik vanavond nog eens naar kijken, had niets bijzonders gezien, maar als ik ze weer eens laat syncen komt het snel zat naar boven.

Heb nu de boel op enkele schijf aangesloten en ben backups aan het trekken. Daar iig geen fouten bij te zien.

[ Voor 31% gewijzigd door dion_b op 14-10-2014 14:14 ]

[dion_b]

Zo, backup gedraaid. Vervolgens weer beide drives erin gehangen en de tweede weer toegevoegd aan het array. En...

...exact zelfde snelheid als voorheen, gemiddeld zo'n 340kB/s

Nu voor zekerheid:
- nul meldingen in dmesg of /var/log/syslog van na start sync
- CPU is meestal 99.7% idle
- bijna 3GB van de 4GB is free
- IO wait is meestal 0,0, wat af en toe (1x/2min) omhoog schiet naar 25% door udiskd

Iemand nog een idee? Zo niet ga ik de boel later vanavond of anders morgenavond gewoon from scratch opnieuw inrichten en kijken wat dat uithaalt...

[johnkeates]

Ander idee: heb je nog een extra disk of partitie ergens die je kan gebruiken? Als je namelijk (weer los sdb en sdc) arrays met een andere disk erbij kan maken kan je het wat beter meten.

Dus stel dat je nog een LV of een disk ergens hebt waar je een partitie van bijv. 2GB op kan maken, en eenzelfde partitie op sdb en sdc maakt, en dan een sdaX + sdb1 RAID1 gaat builden en daarna een sdaX + sdc1 RAID 1, dan kan je misschien met wat meer zekerheid vaststellen waar het probleem ligt.

Andere optie om je eigen configuratie compleet buiten te sluiten: start met een live cd of live usb systeem op. Slax, GRML, maakt niet uit, als het maar live draait met z'n eigen config en mdadm heeft. Als je daar dan wel snel een array mee kan builden weet je dat het dus ergens anders ligt dan bij je disks of hardware.

[dion_b]

johnkeates schreef op woensdag 15 oktober 2014 @ 22:16:
Ander idee: heb je nog een extra disk of partitie ergens die je kan gebruiken? Als je namelijk (weer los sdb en sdc) arrays met een andere disk erbij kan maken kan je het wat beter meten.

Dus stel dat je nog een LV of een disk ergens hebt waar je een partitie van bijv. 2GB op kan maken, en eenzelfde partitie op sdb en sdc maakt, en dan een sdaX + sdb1 RAID1 gaat builden en daarna een sdaX + sdc1 RAID 1, dan kan je misschien met wat meer zekerheid vaststellen waar het probleem ligt.

Geen evengrote 1.5TB schijf, maar wel de 60GB oude OS-schijf waar partitie van paar GB geen probleem zou zijn.

Andere optie om je eigen configuratie compleet buiten te sluiten: start met een live cd of live usb systeem op. Slax, GRML, maakt niet uit, als het maar live draait met z'n eigen config en mdadm heeft. Als je daar dan wel snel een array mee kan builden weet je dat het dus ergens anders ligt dan bij je disks of hardware.

Heb al een compleet andere OS install gedaan, maar dan wel de bestaande config mee geassembleerd.

Stappenplan nu:
1) probeer het gewoon met deze twee drives in nieuwe array from scratch. Indien goed: mooi, fout in config ergens.
2) zo niet, zelfde proberen vanaf live USB.
3) zo niet, 60GB schijf erbij trekken en testvolumes maken met steeds een van de twee grote jongens.

[chronoz]

code:

smartctl -a /dev/sdb | grep result
SMART overall-health self-assessment test result: PASSED
smartctl -a /dev/sda | grep Pending
197 Current_Pending_Sector  0x0000   000   000   000    Old_age   Offline      -       0

SmartCTL zegt PASSED en Current_Pending_Sector op 0?

code:

hdparm -tT /dev/sdb

Wat betreffende de prestaties van individuele disken?

[ Voor 13% gewijzigd door chronoz op 17-10-2014 13:02 ]

[jbhc]

Ik gok op 2 (bijna)defecte schijven. Laat me raden; tegelijk gekocht?

[dion_b]

Alsnog een gare disk, maar eentje die zich erg goed kon verstoppen

hdparm -tT /dev/sdb geeft readsnelheden rond de 90MB/s, ongeacht hoe vaak je het draait.
hdparm -tT /dev/sdc ook - de eerste keer. Daarna dit:

code:

/dev/sdc:
 Timing cached reads:   12574 MB in  1.99 seconds = 6305.79 MB/sec
 Timing buffered disk reads: 224 MB in  3.01 seconds =  74.36 MB/sec
dionb@Thalia ~ $ sudo hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   12548 MB in  1.99 seconds = 6293.17 MB/sec
 Timing buffered disk reads: 238 MB in  4.64 seconds =  51.33 MB/sec
dionb@Thalia ~ $ sudo hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   12622 MB in  1.99 seconds = 6329.56 MB/sec
 Timing buffered disk reads:  96 MB in  3.01 seconds =  31.94 MB/sec
dionb@Thalia ~ $ sudo hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   12344 MB in  1.99 seconds = 6190.38 MB/sec
 Timing buffered disk reads:  68 MB in  3.00 seconds =  22.64 MB/sec
dionb@Thalia ~ $ sudo hdparm -Tt /dev/sdc

/dev/sdc:
 Timing cached reads:   12436 MB in  1.99 seconds = 6236.40 MB/sec
 Timing buffered disk reads:  20 MB in  3.00 seconds =   6.67 MB/sec

Frappante is dat er nog steeds niets in syslog of dmesg of waar dan ook te vinden is, maar het lukt met dezelfde instortende performance niet om een SMART selftest te voltooien.

code:

=== START OF READ SMART DATA SECTION ===
SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Short offline       Completed: unknown failure    90%     19179         -

Meh, wordt nieuwe drive scoren. Jammer dat ik zo lang over m'n troubleshooting gedaan heb door aanvankelijk maar een keer hdparm -tT te doen

[johnkeates]

Is de stervende schijf toevallig een stuk heter dan de ander?

$sudo hddtemp /dev/sd[a-z]

Slechte performance wordt helaas niet vaak door SMART als probleem gezien

[dion_b]

Niet noemenswaardig, beide waren lauwwarm. Maar goed, stervende is nu in kliko en ga er ook geen tijd meer aan besteden. Vanmiddag verwacht ik 2x 2TB binnen te krijgen (1.5TB was niet meer leverbaar, dus gelijk twee nieuwe gehaald).

[HollowGamer]

Het kan soms raar zijn. Sowieso is S.M.A.R.T. (helaas) niet erg betrouwbaar.

Een schijf kan bijv. in een keer kapot gaan of toch goede waardes geven in S.M.A.R.T.
Conclusie: als de schijf bestanden corrupt, low performance geeft, .. meestal hardware probleem.

[dion_b]

Bestanden waren gelukkig niet corrupt, en sowieso had ik meerdere backups van alle echt persoonlijke data (documenten, foto's), dus no problem.

Maar goed, nieuwe schijven zijn binnen en geinstalleerd. De boel is aan het syncen- nu met zo'n 110000K/sec - verschil is merkbaar, het zou in zo'n 4.5u klaar moeten zijn nu