=?iso-8859-2?q?v=E1hav=FD?=, =?iso-8859-2?q?loudav=FD?=, usínající S.M.A.R.T. self test

[Slavek Banko]

Dne st 13. května 2009 Petr Stehlik napsal(a):
> Zdar ve středu,
>
> mám disk Seagate Barracuda ES ST3320620NS (firmware 3.AEG), který byl
> se stejným bráchou v Linux SW RAID1, každou noc na nich probíhaly short
> S.M.A.R.T. self testy (díky smartmontools) a jednou týdně long testy a
> vše bylo v pořádku.
>
> Pak jsem upgradoval kernel z 2.6.22 na 2.6.26 a dělal ještě pár změn a
> naráz jsem si všiml, že ty self testy neprobíhají - že prostě zůstávají
> trčet na třeba "90%" (či jiné hodnotě) celé týdny.
>
> Vypadalo to, že je to způsobené tím upgradem kernelu, takže jsem
> upgradoval ještě smartmontools a když to nepomohlo, tak jsem nakonec
> vyměnil jeden z těch Seagatů v RAID1 za Western Digital a ten uvolněný
> Seagate jsem zapojil do testovacího stroje na pokusy.
>
> Zajímavá fakta:
>
> 1) self testy na Western Digitalu probíhají OK, na Seagatu pořád
> zůstávají trčet - takže to nevypadá na chybu (upgrade) kernelu, anebo
> se to projevuje jen ve spojitosti s tímto konkrétním Seagate diskem.
>
> 2) pokud se opakovaně ptám na stav self testu (watch 'smartctl -l
> selftest /dev/sdX'), tak ho během pár minut "dostrkám" z těch zatuhlých
> XX% až do úspěšného(?) konce - otázka samozřejmě je, jak moc můžu
> takovým výsledkům věřit...
>
> 3) pokud na testovacím stroji nabootuju z jiného disku, tak short self
> test na tom uvolněném Seagatu proběhne ihned (do minuty) tak, jak má.
>
> 4) pokud na testovacím stroji nabootuju normálně z toho Seagate disku,
> tak short self test probíhá podle toho, kolik věcí běží (a tedy
> čte/zapisuje na ten disk) - konkrétně pokud všechny služby a démony
> zastavím, tak short self test je do minuty OK, pokud pustím NUT
> (Network UPS Tools), tak se short self test zasekne hned na začátku
> (90%), pokud spustím virtuální servery (linux-vservers), tak v
> závislosti na tom, které spustím se short self test (normálně minutový)
> protahuje klidně na 10 minut i déle, případně opět usne a nepokračuje
> vůbec. Testovací stroj přitom není zapojen do internetu, takže spuštěné
> služby a virtuály by neměly nic moc dělat, vše je poměrně idle - přesto
> to jaksi ovlivňuje ten S.M.A.R.T. selftest.
>
> Je obtížné to nějak lépe zdokumentovat, protože prostým pozorováním
> děje (smartctl -l selftest) děj výrazně ovlivňuji (viz postrkování).
>
> Moc by mě zajímalo, jestli se někdo setkal s podobným chováním
> S.M.A.R.T. self testů a má-li tušení, jak ten systém opravit tak, aby
> ty testy na tom Seagatu opět probíhaly normálně.
>
> Dodávám, že tu mám řadu jiných strojů v téměř stejných HW i SW
> konfiguracích a takovýto problém s usínajícími S.M.A.R.T. testy jsem
> nikde jinde nezaznamenal.
>
> Díky
>
> Petr
>
> P.S. perlička: po jednom vypnutí/zapnutí stroje se ten Seagate už
> prostě nepřihlásil na sběrnici, vypadá zcela elektronicky mrtvý, ale
> nahradil jsem ho záložním diskem s jen nepatrně novějším firmware
> (3.AEK), který se chová naprosto stejně problematicky.
>

Tak to je zajímavé!

Prakticky totožný problém jsem nedávno také zaznamenal na jednom ze svých 
serverů. Kombinace 4× WD, 4× Seagate - na všech WD long selftest proběhl 
bez komplikací. Na dvou Seagate, které jsou v poli pro zálohování také 
proběhl bez komplikací. Na dvou Seagate, které jsou v poli s "živými" 
systémy (včetně virtuálních) 90% a žádný vývoj.

Toť po aktualizaci z jádra Etche na Lennyho. Protože se nám na tom stroji 
pak několikrát dostával proces "md2_raid5" do stavu "D", z čehož ty 
systémy neměly radost (a uživatelé překvapivě také ne), tak jsme zatím 
systém vrátili zpět na Etche... Na další výzkum jsem neměl prostor.

Slávek