[LSI 8708elp] Schijf alweer uit de raidarray gekickt

[Keiichi]

Het laatste half jaar zijn 3 schijven door LSI 8708elp uit de raidarray gekickt. Elke keer bleek er niets mis te zijn met de schijf.

De logs laten het volgende zien:
- Enkele timeouts op de PD
- Reset van de PD
- Removal van de PD
- Degradatie van de VD
- Status change van de PD van online naar failed
- Status change van de PD van failed naar unconfigured bad
- Insert van de PD

De schijven zijn seagates Barracuda ES.2 (500GB)

Omdat het al paar keer gebeurd is, maak ik me natuurlijk zorgen. Maar ik niets logisch bedenken waardoor dit komt.

Wat kan hier allemaal mis mee zijn?

[Anoniem: 191050]

Heb je de schijf al eens vervangen? Volgende stap is de backplane controleren en de kabel.

[Keiichi]

Anoniem: 191050 schreef op woensdag 25 mei 2011 @ 13:18:
Heb je de schijf al eens vervangen? Volgende stap is de backplane controleren en de kabel.

2 van de 3 schijven waren sowieso nieuwe schijven. De eerste was nieuw (in de zin van coldspare), de tweede was Refurbished (Er was al eens eerder een schijf echt kapot gegaan) en de laatste was dan een schijf die al eerder in de array gehangen heeft/.

Ik kan geen fysieke onregelematigheden constateren op de kabels en backplane.

[Anoniem: 191050]

De enige manier om dat echt te testen is deze te vervangen door een ander exemplaar. Dat de schijf nieuw is betekent niet dat hij niet stuk kan zijn of hikjes kan vertonen. De backplane en kabels hoeven ook geen zichtbare schade te hebben om issues te hebben. Kwestie van 1 voor 1 vervangen om dit uit te sluiten.

Is het spul zakelijk in gebruik (met eventueel support contracten?) of voor thuis?

[Keiichi]

Zakelijk, en ik ben de support

het is vrij lastig om door trial&error de fout te vinden. Het gaat maanden aan een stuk zonder probleem namelijk.

[Voor 63% gewijzigd door Keiichi op 25-05-2011 14:38]

[KermieCow]

Staan de schijven wel op de compatible hardwarelijst ( inclusief firmware ) van de controller? Hier hebben we bij een klant van ons veel problemen mee. De schijven worden na div. fouten uit de raid gezet. Na een keer terug invoeren werken de schijven gewoon weer, ook als via een andere pc wordt gekeken, lijkt er niets mis met de schijf. Nadat de schijven geflashed zijn naar een nieuwere firmware ( die wel op de comp. lijst staat ) blijven ze netjes werken.

Edit:
Dat is trouwens ook met de Baracude ES.2 versies, maar dan de 750GB uitvoering. Firmware SN05 gaf problemen. Vanaf SN06 of SN16 is alles in orde.

[Voor 14% gewijzigd door KermieCow op 25-05-2011 14:43]

[Anoniem: 191050]

Ik snap dat het lastig is om het via trial en error te doen, maar dat is eigenlijk wel de enige manier om het zeker te weten. Je zou als er nog een bay vrij is de RAID kunnen laten rebuilden op een andere bay wanneer de disk er weer eens uit wordt gegooid, dan kun je die bay al dan niet uitsluiten.

[Keiichi]

Anoniem: 191050 schreef op woensdag 25 mei 2011 @ 14:49:
Ik snap dat het lastig is om het via trial en error te doen, maar dat is eigenlijk wel de enige manier om het zeker te weten. Je zou als er nog een bay vrij is de RAID kunnen laten rebuilden op een andere bay wanneer de disk er weer eens uit wordt gegooid, dan kun je die bay al dan niet uitsluiten.

Dat heb ik al gedaan. Ben nu al 2 bays totaal opgeschoven

De schijf staat niet exact op de lijst, wel z'n 'broertjes' (1TB, 750GB)

[Anoniem: 191050]

Aah ok, en er zitten in die backplane wel meerdere disks? Dan zou ik toch beginnen met de disk zelf vervangen.

[KermieCow]

Keiichi schreef op woensdag 25 mei 2011 @ 15:05:
[...]


Dat heb ik al gedaan. Ben nu al 2 bays totaal opgeschoven

De schijf staat niet exact op de lijst, wel z'n 'broertjes' (1TB, 750GB)

en de firmwareversie van je schijf?
Is er een nieuwere beschikbaar?
Op deze link kun je zien of jouw schijf wel of geen update zou moeten hebben :
http://seagate.custkb.com...e/search.jsp?DocId=207963

[Keiichi]

Het gaat niet om 1 en dezelfde schijf waarbij het plaats vind.

Er is een nieuwere firmware versie beschikbaar. Er staat SN04 op en SN06 is uit. (In ieder geval voor de schijf die als laatst eruit gekomen is)

[KermieCow]

Keiichi schreef op woensdag 25 mei 2011 @ 15:22:
Het gaat niet om 1 en dezelfde schijf waarbij het plaats vind.

Er is een nieuwere firmware versie beschikbaar. Er staat SN04 op en SN06 is uit. (In ieder geval voor de schijf die als laatst eruit gekomen is)

Nee, ok, maar wel allemaal dezelfde serie en oudere ( SN04 en SN05 ) firmware?

Ben er hier ook een aantal maanden mee bezig geweest, heen en weer mailen met de support van de RAID controllers en de support van Seagate, daaruit kwam dat er problemen waren met de SN05 ( en ouder ) firmware's van de baracuda ES.2 schijven. Destijds stonden de ES.2 SN05 nog als compatible op de lijsten, later is dat aangepast naar SN06/SN16.

De eerste problemen traden op na zo'n 8 maanden na oplevering van de systemen ( 13 storage system, ieder 12 750 gb schijven ), regelmatig ( lees 1 tot 2 per week ) schijven die uit de raid gegooid worden. Nu draait het systeem zo'n 2,5 jaar, nog steeds regelmatig schijven met firmware SN05 die er mee ophouden. De schijven met firmware SN06/SN16 zitten er dus ruim 1,5 jaar in, daarvan nog niet 1 uitgevallen.

[Anoniem: 15758]

Ondersteunen je HDDs TLER? Is die ingesteld op 7 seconden? Heb je de SMART-data geanalyseerd op Current Pending Sector en Reallocated Sector Count?

Kortom, ben je op de hoogte dat bad sectors ervoor zorgen dat schijven uit de RAID-array worden geschopt bij 90% van alle hardware RAID?

[Keiichi]

Anoniem: 15758 schreef op woensdag 25 mei 2011 @ 17:43:
Ondersteunen je HDDs TLER? Is die ingesteld op 7 seconden? Heb je de SMART-data geanalyseerd op Current Pending Sector en Reallocated Sector Count?

Kortom, ben je op de hoogte dat bad sectors ervoor zorgen dat schijven uit de RAID-array worden geschopt bij 90% van alle hardware RAID?

Testen die ik met uit de array gekickte schijven gedaan hebben was o.a. een volledige badblocks check (van e2fsutils) waarbij er geen bad blocks tevoorschijn kwamen, geen reallocated sectors in de smart informatie. (pending sectors niet op gelet)

Ik denk dat ik langzamerhand de schijven moet gaan voorzien van een firmware update, als ik KerrieCow zo hoor

[Anoniem: 15758]

e2fsutils is een filesystem utility. Je RAID laag zit daar tussen, dus ik weet niet precies wat je gedaan hebt.

Heb je de schijven die uit de array zijn gekickt weer toegevoegd, of iets anders mee gedaan? Zo ja, dan verdwijnen de bad blocks automatisch door de rebuild.

In geen van alle schijven zie je Reallocated Sector Count? Raw value is 0? Zo ja, dan nog steeds kun je last hebben gehad van bad sectors, echter van het type dat geen fysieke schade heeft opgelopen maar simpelweg onvoldoende ECC correctie beschikbaar was. Het overschrijven van die sectors betekent dat er geen enkel spoor meer te bekennen is dat het ooit is gebeurd.

Vandaar dat ik vraag of je na het uit de array kicken iets met die schijf hebt gedaan. Heb je op dat moment op een andere computer op een normale controller de SMART uitgelezen? Dat is namelijk wat ik zou doen.

Verder is Current Pending Sector de allerbelangrijkste SMART-value die er bestaat, en de reden dat er dagelijks bij heel veel mensen disks uit de array worden getrapt. Helaas kun je niet zien of die waarde ooit non-zero is geweest; want na het overschrijven van de bad sector reset die waarde weer naar 0.

[Keiichi]

Anoniem: 15758 schreef op woensdag 25 mei 2011 @ 18:53:
Vandaar dat ik vraag of je na het uit de array kicken iets met die schijf hebt gedaan. Heb je op dat moment op een andere computer op een normale controller de SMART uitgelezen? Dat is namelijk wat ik zou doen.

Dat is ook wat ik gedaan heb. Ik krijg de smart niet direct uitgelezen via de controller (Althans, ik heb het op de testbank ooit 1x gedaan, waarna de server plat ging.)

Verder is Current Pending Sector de allerbelangrijkste SMART-value die er bestaat, en de reden dat er dagelijks bij heel veel mensen disks uit de array worden getrapt. Helaas kun je niet zien of die waarde ooit non-zero is geweest; want na het overschrijven van de bad sector reset die waarde weer naar 0.

Met de schijf die er nu uit ligt ga ik morgen eens kijken wat de waarde daarvan is.

[Anoniem: 15758]

Een RAID controller betekent dat je geen rechtstreeks toegang hebt tot SMART-data, hooguit via een passthrough methode. Daarom dat ik aanraad de schijf op een andere non-RAID controller aan te sluiten. Makkelijkst is een andere PC op de chipset SATA in IDE of AHCI mode, dan liefst met Linux booten of iets wat niet gaat rommelen met de schijf.

Als je de schijf in Windows opstart, zorg dan dat je zeker NIET de schijf 'initialiseert' - daarmee schrijft windows naar de schijf. Behalve corruptie betekent dat ook dat een eventueel probleem gemaskeerd kan worden.

[Mr Alfabet]

Je kunt ook via de controller (dat kan ik tenminste op mijn areca) een volume check uitvoeren, daarbij worden alle schijven 100% belast. Vliegt de schijf er dan weer uit dan weet je dat het gewoon een defecte schijf is.

[Anoniem: 15758]

Volume check gaat niet over schijven die geen onderdeel meer zijn van de array. Bovendien weet je niet wat zo'n check doet, als die een bad sector overschrijft en zegt dat de check 100% klaar is, weet je nog niet wat de oorzaak is geweest. SMART is je beste hulpmiddel hier, maar die moet je dan wel op het juiste moment uitlezen, in principe direct na het uit de array vallen van een schijf, zonder dat er verder iets anders met die schijf is gebeurd (zoals het weer toevoegen aan de array).

[Mr Alfabet]

Anoniem: 15758 schreef op woensdag 25 mei 2011 @ 19:25:
Volume check gaat niet over schijven die geen onderdeel meer zijn van de array. Bovendien weet je niet wat zo'n check doet, als die een bad sector overschrijft en zegt dat de check 100% klaar is, weet je nog niet wat de oorzaak is geweest. SMART is je beste hulpmiddel hier, maar die moet je dan wel op het juiste moment uitlezen, in principe direct na het uit de array vallen van een schijf, zonder dat er verder iets anders met die schijf is gebeurd (zoals het weer toevoegen aan de array).

Ik had het dan ook over een volume check terwijl de schijf terug in de array zit. En als de bad sector overschreven wordt, prima toch? Vaak geeft zo'n volume check echter een error bij de disk, en geeft dan ook aan welke disk. Als die de schijf er uit gooit, weet je dat ie defect is.

[Anoniem: 15758]

Als de schijf 'terug in de array zit' betekent dat er een rebuild is uitgevoerd, dat wist alle bewijs en mogelijkheid uit te vinden wat het probleem nu was.

Ik denk dat de TS niet gebaat is om elke keer maar weer uitvallende schijven te hebben, maar nu eens achter de oorzaak te komen. In dat geval wil je niet dat het bewijsmateriaal vernietigd wordt door zo'n rebuild.

Dat is netzoiets van, er is een moord gepleegd, laten we het plaats delict snel opruimen en schoonmaken dan lijkt het alsof er niks is gebeurd. Echter loopt de moordenaar dan nog steeds rond en krijg je binnen de kortste keren weer zo'n plaats delict. Dat is alleen symptoonbestrijding en daarmee negeer je het onderliggende probleem.

Het is ook gevaarlijk, want straks vliegen er twee schijven uit en is je array failed. Dan heb je een probleem kan ik je vertellen. Ook tijdens een rebuild als een andere schijf dan een weak sector heeft ben je de sjaak. Dat is ook de hele kern van het verhaal van deze artikelen:

Why RAID 5 stops working in 2009
Why RAID 6 stops working in 2019

[Keiichi]

LSI controllers doen wekelijk automatisch (factory default setting) een patrol read. Dit komt denk overeen met een volume check.

Deze was niet actief op het moment dat een schijf gekicked werd.

code:

197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0

De current pending sectors staat op 0.

De laatste schijf gaat hier nu op de pijnbank

-edit-

Even de complete smart informatie:

code:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   108   084   006    Pre-fail  Always       -       18421227
  3 Spin_Up_Time            0x0003   094   094   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       29
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   070   060   030    Pre-fail  Always       -       387442885056
  9 Power_On_Hours          0x0032   068   068   000    Old_age   Always       -       28504
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       29
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   001   001   000    Old_age   Always       -       2236
188 Command_Timeout         0x0032   099   099   000    Old_age   Always       -       8590065666
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   064   058   045    Old_age   Always       -       36 (Lifetime Min/Max 36/36)
194 Temperature_Celsius     0x0022   036   042   000    Old_age   Always       -       36 (0 15 0 0)
195 Hardware_ECC_Recovered  0x001a   037   034   000    Old_age   Always       -       18421227
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Zijn er verder nog onregelmatigheden in te ontdekken? De waardes van Command_Timeout en Reported_Uncorrect zien er volgens mij ook niet heel erg goed uit.

[Voor 71% gewijzigd door Keiichi op 26-05-2011 08:29]

[Keiichi]

Alle harde schijven zitten op SN06 of SN16, maar ik heb 2 dagen op een rij dat een schijf gekickt word.

De laatste is na een command timeout eruit gegooid en de vorige na een unexpected sense.



Er zijn nu 4 nieuwe harde schijven onderweg ter vervaning van.