Hoe dood is mijn schijf?

[Xudonax]

Ik heb recentelijk (afgelopen maandag meen ik) een set van 6 Hitachi Deskstar 5K1000 laptop schijfjes ontvangen voor gebruik in een RAID-Z2 configuratie met ZFS. Echter, na ~94 uur houd een van de schijven er al mee op. Initieel leek het enkel een aantal I/O errors te zijn, maar na herstarten wilde heel mijn machine niet meer starten (ZFS wacht schijnbaar tot deze schijf iets laat horen op Linux).

Hieronder heb ik de uitvoer van smartctl staan, kan iemand zeggen of deze schijf nog te redden is (bijv. door helemaal vol te schrijven met 0 bytes) of dat deze gewoon retour moet? Het verwijderen van de schijf is namelijk nogal een rotwerk

De schijf hangt aan een Marvell Technology Group Ltd. 88SE9120 SATA 6Gb/s Controller (rev 12) controller volgens lspci. Dit is niet mijn eerste keus, maar ik heb mijn SAS->SATA kabels nog niet ontvangen. Tot die tijd moet ik het dus met deze Marvell controller doen. Deze zit op een Asus U3S6 kaart, waarvan ik enkel de SATA poorten gebruik.

Ik heb nog geen SMART Self Test gedaan, maar kan deze natuurlijk wel doen indien gewenst.

Ook als ik met dd van de schijf probeer te lezen gaat dit fout, in dit geval na grofweg 9.5MByte. Ook is de snelheid te laag, deze hoort rond de 80 tot 90MByte/s te zijn.

code:

[root@localhost ~]# dd if=/dev/sdg of=/dev/zero bs=8M
dd: reading ‘/dev/sdg’: Input/output error
1+2 records in
1+2 records out
9486336 bytes (9.5 MB) copied, 74.977 s, 127 kB/s

code:

nutteloze rommel stond hier ^_^;;

[ Voor 88% gewijzigd door Xudonax op 29-12-2012 18:27 ]

[Verwijderd]

Post de SMART data; wat je nu post is allemaal onzin.

smartctl -A /dev/...

Het is overigens wel zéér vreemd dat je problemen zou krijgen aangenomen dat dit om bad sectors gaat. ZFS zou die automatisch moeten corrigeren. Wat je zou kunnen doen is een ZFSguru livecd booten en daar de pool importeren en een scrub starten. Dan zou je in de SMART gegevens moeten zien dat je bad sectors weg zijn en in de pool status output dat er read errors waren en dat die zijn gecorrigeerd.

Als Linux dit niet zelf kan, is de ZFS-on-Linux duidelijk inferieur aan FreeBSD en Solaris oplossingen.

[Xudonax]

Nuttigere SMART data:

code:

[root@localhost /]# smartctl -A /dev/sdg -d ata
smartctl 5.43 2012-06-30 r3573 [x86_64-linux-3.6.6-3.fc18.x86_64] (local build)
Copyright (C) 2002-12 by Bruce Allen, http://smartmontools.sourceforge.net

Error SMART Thresholds Read failed: Input/output error
Smartctl: SMART Read Thresholds failed.

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   ---    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   100   100   ---    Pre-fail  Offline      -       0
  3 Spin_Up_Time            0x0007   176   176   ---    Pre-fail  Always       -       1
  4 Start_Stop_Count        0x0012   100   100   ---    Old_age   Always       -       13
  5 Reallocated_Sector_Ct   0x0033   100   100   ---    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   ---    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   100   100   ---    Pre-fail  Offline      -       0
  9 Power_On_Hours          0x0012   100   100   ---    Old_age   Always       -       95
 10 Spin_Retry_Count        0x0013   100   100   ---    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       13
191 G-Sense_Error_Rate      0x000a   100   100   ---    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   ---    Old_age   Always       -       0
193 Load_Cycle_Count        0x0012   100   100   ---    Old_age   Always       -       509
194 Temperature_Celsius     0x0002   253   253   ---    Old_age   Always       -       23 (Min/Max 17/32)
196 Reallocated_Event_Count 0x0032   100   100   ---    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   ---    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   ---    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   ---    Old_age   Always       -       0
223 Load_Retry_Count        0x000a   100   100   ---    Old_age   Always       -       0

Ik zal de oude even eruit knippen. Ik ga even herstarten en kijken of ik genoeg geduld heb om te wachten totdat het geheel opgestart is. ZFS-on-Linux bied wel scrubs, die heb ik (redelijk recent) nog gedraait om te kijken hoe dat ging.

EDIT: Ok, met wat trucjes heb ik de bak op kunnen starten, en er draait nu een scrub. Wel is de link naar sdg (de "defecte" schijf) al een aantal maal gereset en gaat vooral het SATA commando READ CAPACITY erg vaak fout als ik de kernel output zo bekijk. En als ik nu in zpool status kijk dan is de status van de schijf van FAULTED veranderd naar REMOVED... Oeps?

[ Voor 6% gewijzigd door Xudonax op 29-12-2012 18:34 ]

[Verwijderd]

Die SMART data ziet er prima uit. Je moet kijken naar de raw value van Current Pending Sector. Deze staat op 0 bij deze schijf. Dit hoort zo voor alle schijven te zijn. Kun je dit controleren?

Het vervelende van SMART is dat je niet terug in de tijd kunt gaan. Omdat jij een surface scan hebt gedaan, kan het zijn dat bewijs is vernietigd. Je zult zo nooit weten wat het probleem was, hooguit de hoop dat je het opnieuw kunt reproduceren.

Als geen van je schijven bad sectors laten zien, zou je ook geen I/O errors mogen krijgen. Mogelijk krijg je die nu niet meer als je opnieuw die dd surface scan gaat draaien. Dat is namelijk een actieve ingreep en niet passief.

Kortom, dit is een stuk moeilijker. Je zult moeten blijven reproduceren totdat je weer hetzelfde probleem krijgt, en dan niets anders doen dan DIRECT de SMART uit te lezen. Als daaruit blijkt dat je een pending sector hebt, bevestigt dat mijn verhaal. Het kan echter zijn dat het heel lang duurt voordat je weer een zelfde situatie kunt reproduceren, dan heb je pech.

Wat ook zou kunnen, is dat je kabelproblemen hebt gehad op andere disks. Dit kun je zien aan UDMA CRC Error Count. De SMART log die je nu hebt gepost ziet er keurig en maagdelijk uit, in elk geval.

[Xudonax]

Ik heb geen SMART tests oid gedaan. Of doel je op de dd? Ik kan de informatie nu reproduceren omdat de schijf dus weer loopt te bokken op dit moment. Ik zal eens even kijken...

EDIT: Sterker nog, ik kan nu helemaal niet meer bij de schijf komen. meldingen dat READ CAPACITY(16) mislukt e.d. Ik zal even een foto maken...

[ Voor 29% gewijzigd door Xudonax op 29-12-2012 18:39 ]

[Verwijderd]

Hm dat is wel vreemd. Want in elk geval de schijf die je hierboven post heeft geen kabelproblemen en geen bad sectors. Dat laatste weet je niet 100% zeker omdat vóór en tijdens de dd zero-write je wel bad sectors had kunnen hebben, maar door het lezen worden die recovered. Daarom is een surface scan een actieve utility. Als tijdens die surface read een bad sector wordt recovered zonder fysieke schade, dan wordt elk bewijs hiervan vernietigd en zie je gewoon Current Pending Sector en Reallocated Sector Count op 0 staan, terwijl Current Pending Sector wel op 1 of hoger stond vóórdat je aan de zero-write of surface scan begon.

Maar als je nu zegt dat de schijf onbenaderbaar is geworden, ga ik toch twijfelen. Dan kan er iets anders aan de hand zijn. Kun je die schijf ook even op een normale chipset controller aansluiten en niet op de Marvell controller? Dat zou eventueel een oorzaak kunnen zijn.

[Xudonax]

Dat is dus net het punt, in principe zitten alle aansluitingen vol... 4 op het moederbord en 2 op de Marvell controller. Ik zal even kijken of de kabellengte het aankan om wat te wisselen, ik denk dat dat wel kan. En ik las vanaf /dev/sdg náár /dev/zero, of is dit wat je bedoelt met surface scan?

Also, fotootje van de exacte foutmeldingen als ik nu smartctl -A -d ata /dev/sdg doe:

(Niet helemaal super scherp ivm telefoon)

Ik ga in ieder geval eens even met de kabels rommelen...

[Verwijderd]

Een surface scan wil zeggen dat je alle sectoren op een opslagapapparaat opvraagt. Zo ontdek je bad sectors of je komt ze in elk geval tegen. Als je een hardeschijf een bad sector laat laten, probeert hij deze te recoveren. TLER-schijven houden daar na 7 seconden mee op, consumentenschijven tot 120 seconden. Overigens, normaliter lees je van /dev/zero en schrijf je naar /dev/null. Schrijven naar /dev/zero lijkt soms ook te werken, maar of dat de bedoeling is vraag ik mij af.

In de output die je hierboven post mis ik overigens '-d ata' wat denk ik voor jouw controller vereist is? Ik zou in elk geval aanraden om te testen door deze disk op je chipset controller aan te sluiten. Dat mag prima met een andere kabel; kabelfouten zou je sowieso moeten kunnen zien in de SMART output (UDMA CRC Error Count). Het kan prima zijn dat de drivers voor die Marvell controller niet lekker werken, en dat dat je probleem is terwijl de schijf zelf prima functioneert.

[ Voor 9% gewijzigd door Verwijderd op 29-12-2012 18:54 ]

[Xudonax]

Ik heb de kabels verwisseld (er hangt nu een willekeurige andere schijf uit diezelfde pool op de Marvell controller) en nu start alles gewoon meteen door en is er niets aan de hand... Dit vind ik op z'n minst een beetje heel erg bizar. Als de controller fout zit dan moet deze fout blijven zitten, en aan de kabels heb ik niet gezeten... En de Marvell kabels stonden ook absoluut niet strak, dus dat kan ook niet de oorzaak zijn.

In ieder geval werkt het nu, en weet ik al wat ik ga doen zodra ik de SAS-8087 naar SATA kabels ga doen. Alles opnieuw bekabelen met die dingen zodat het op een fatsoenlijke controller hangt (ik heb de IBM M1015 hier liggen hiervoor).

[Verwijderd]

Dan zou ik nog eens flink gaan testen met de (andere?) schijf die nu aan de Marvell hangt. Ga daar eens veel I/O mee doen zoals surface reads en kortom, laat wat data stromen. Als je dezelfde problemen ervaart als met de eerste disk die aan deze controller hing, dan lijkt het toch aan de controller of driver te liggen.

Niet altijd is hetzelfde probleem accuraat te reproduceren, dus als nu alles goed werkt denk je wellicht dat het is 'opgelost'. Maar het kan prima zijn dat je volgende week weer hetzelfde probleem krijgt. Dit soort problemen kunnen lastig zijn. Mijn advies: blijf zoeken, blijf het probleem isoleren totdat je weer wanneer het soms/altijd optreedt en wanneer het helemaal niet optreedt.

[Xudonax]

Tsja, ZFS is nu aan het resilveren, dus dat lijkt me ook al een aardige belasting. Ik zal in ieder geval nog eens even aan de gang gaan.

EDIT: En hebbes. Marvel heeft er gewoon geen zin in. Naja, ik kan die twee schijven in principe missen in mijn RAID-Z2 setup dus echt zorgen erover maken doe ik niet. Maar dit is wel een teken dat die IBM controller er ASAP in moet. En sowieso gaat die machine vanavond uit voor de komende paar dagen, dus er kan niet héél veel mis gaan lijkt me.

[ Voor 56% gewijzigd door Xudonax op 29-12-2012 19:21 ]

[Xudonax]

Zo, gisteren eindelijk mijn SAS 8087 naar SATA kabels binnen gekregen, en de Marvell controller een schop terug gegeven naar mijn Windows machine voor de USB3 poorten op die kaart

Er loopt op dit moment een scrub op de ZFS pool, en so far so good. Ik denk dat dit idd een stukje incompatibiliteit oid met die Marvell controller was. Opgelost nu dus \o/