Dotaz: Pravidelná kontrola diskov

[AraxoN]

Kontrolujete pravidelne svoje rotačné disky? Ak áno - ako?

My sme zatiaľ robili kontroly mesačne, takým spôsobom, že sme fyzické disky nechali cez príkaz dd prečítať od začiatku po koniec a potom sledovali, či sa nezhoršili niektoré vybrané SMART parametre. Toto fungovalo celkom dobre, pri 146GB a 300GB diskoch to bolo prakticky hneď. Ale disky sú stále väčšie. Už pri 2TB to je na hranici únosnosti, čítanie trvá celý víkend. A teraz prechádzame na 8TB disky, kde by prečítanie celého disku trvalo týždeň a to by kolidovalo s normálnou prevádzkou.

Je pokus o testovanie disku čítaním celého jeho povrchu zbytočný overkill? Je nejaký iný spôsob, ako disk trochu vystresovať a donútiť ho pozrieť sa aj na sektory, ktoré za normálnych okolností nenavštívi?

---

---

Odpovědi

[ewew]

Osobne spúšťam dlhú kontrolu S.M.A.R.T na pevných diskoch 500GB po približne tísíc hodinach a v nepravidelných intervaloch pozriem atribúti.

Možno by niečo odhalilo aj badblocks. Lenže tento typ testu je čítaci čo nemusí odhaliť problémy pri zápise.

Tento spôsob môže aj nemusí byť správny.

[AraxoN]

Tak my vybrané SMART parametre kontrolujeme každých 5 minút cez centrálny monitoring. Parametre Reallocated_Sector_Ct, Reallocated_Event_Count, Current_Pending_Sector a Offline_Uncorrectable sa ukázali ako univerzálne dobré prediktory blížiacej sa pohromy. Ten test cez dd je len taký dodatok, aby disk naozaj ukázal, že funguje v celom svojom úložnom rozsahu.

[ewew]

Pri 500GB disku trvá bacblocks -w asi päť a pol hodiny len prvý krok zápis reťazca. je možné, že to robí redukcia ktorá je len SATA1. Inak disk je schopný SATA3.

[paul2no]

Nechápu. Jako že zápis 500 GB disku trvá pět a půl hodiny? To je něco asi špatně. Já teď právě dělám badblocks na jednom 500 GB disku z výzisku, jsem v 37 % druhého zápisu a uběhlo 3:10.

[Peter Golis]

Ewew skontroloval 500GB disk za 5:50H, takže mu to išlo rýchlosťou cca 90GB/H (200Mb/s). Ty si z 500GB skontroloval 37%, teda 185GB za 3:10H, takže ti to išlo rýchlosťou cca 60GB/H (130Mb/s). V reále sa ale nejedná o rýchlosť disku keďže ten test zahŕňa pri nedeštrukčnom teste 3 kroky (prečítanie bloku, jeho zápis a nakoniec prečítanie zapísaných dát aj s ich kontrolou) a pri deštrukčnom len dva kroky (bez prečítania pôvodných dát). Samozrejme že môže mať viacero behov, štandardne sú to myslím 4 behy.

Jediné čo tam teda vidím zle je, že jemu to išlo o polovicu rýchlejšie ako tebe. Možno máš o polovicu pomalší disk, alebo ti uberá diskový výkon niečo iné bežiace na tom stroji. Poprípade si spustil iný test ako on.

[ewew]

badblocks -w -f -vvv disk. Celé to bolo napojené cez USB adaptér pre SATA1/2/3, veľke PATA a malé PATA. Disk WDC black mal len Raw Error Rate 16 a približne osem rokov.

Určite je rozdiel keď ide disk priamo na radič SATA a tiež keď to ide cez USB v čitačke kariet. Inými slovami radič SATA má vlastné IRQ ako USB spoločné pre všetky zariadenia.

[AraxoN]

Pravidelně pouštím smart long testy měsičně a short týdně, a stejně tak týdně btrfs scrub na všech discích. A na starším systému také s mdraid také pravidelně check pole.

Ty tvé doby jsou trochu zvláštní. protože délky čtení rostou se zvyšující se kapacitou pouze s druhou odmocninou kapacity. hustota záznamu se zvýší nejenom v počtu stop, ale i v hustotě ve stopě a proto stejně tak s druhou odmocninou roste rychlost čtení. Mě scrub na 8TB disku čte průměrnou rychlosti 150MB/s (a ti i s tím že vrstva pod btrfs je LUKS) a disk přečte za něco přes 14 hodin.

[Petr Fiedler]

A není to i kontraproduktivní? Pokud to tak pouštíš na nějaký disk např. 7 let, tak je to docela dost zbytečného zapisování a čtení. Netrpí tím ten disk? Já třeba zapíšu za měsíc ~ 3 GB dat. Short jede myslím 1 dokola. U 1 TB disku je to za měsíc 4 TB a long mi jel myslím 4 x dokola. To jsou další 4 TB. Takže běžným používáním zapíšu za měsíc 3 GB a testy by zapsali 8 TB. To je za těch 7 let 252 GB běžných dat a 672 TB testů. Nedostává ten disk takhle zbytečně na frak?

[AraxoN]

SMART testy ničomu neškodia, spúšťame ich každý týždeň a niektoré tie disky majú nabehaných 87-tisíc hodín (skoro 10 rokov nonstop prevádzky). Ale tieto testy rozhodne nekontrolujú celý disk. Ak short zbehne za 2 minúty, celkom určite 2TB neprečítal. Long za 300 minút to asi dá, ale tipujem, že len raz, nie štyrikrát.

[vandrovnik]

U některých rotačních disků je také udávána projektovaná roční zátěž, např. 550 TB (u 8 TB disku Toshiba): 550 Total TB Transferred per Year Workload Rating.

Když si vygooglíte Toshiba MG06ACA800E specification, dočtete se: Workload is defined as the amount of data written, read or verified by commands from host system. Já bych to chápal tak, že i smart long test přispívá k tomu "ošoupání" disku (ostatně ono se to z hlediska ploten nejspíš nijak neliší od čtení dat pro operační systém). U jiných disků mám přes smartd nastavené long testy jednou za týden, ale to by u tohoto disku bylo 8 * 52 = 416 TB workload jen těmi testy, takže jsem dal jen dvakrát měsíčně...

[lertimir]

čtení ničemu neškodí. disk se točí a hlava nad nějakým místem letí. to jestli dál elektronika zpracovává data je skoro jedno.

[j]

To jiste, pri cteni hlava neseekuje a tudiz se vubec (v tomhle pripade naprosto zbytecne) neopotrebovava ...

Tusis ty vubec ze prave seek je nejvetsi zabijak mechanickych disku? Ta magneticka vrstva se zapisama moc neosoupava. Takze generovat jakykoli zbytecny operace je naprosty kravinium.

Vubec poustet tyhle testy je kravina, a zadny normalni pole to nedela. Jednoduse proto, ze si normalni lidi vazne nemuzou dovolit 1/2 z kazdyho mesice testovat, jestli nekde na disku neni badko.

BTW: btrfs scrub na 4x6TB = TYDEN (jo, s nulovym provozem by to hypoteticky bylo za 3 dny). To je naprosto mimo jakoukoli realitu libovolnyho provozu zcela kdekoli.

---

Dete s tim guuglem dopice!

[Heron]

Netrpí tím ten disk?

Ne, číst a zapisovat data je úkol toho disku.

Short jede myslím 1 dokola.

Nejede. SMART Short test jede 1 minutu.

Please wait 1 minutes for test to complete.
Test will complete after Fri Dec 11 21:10:20 2020 CET

long mi jel myslím 4 x dokola

Ne. SMART Long test jede tak dlouho, dokud nepřečte celý disk nebo dokud nenarazí na první nečitelný sektor.

Please wait 636 minutes for test to complete.
Test will complete after Sat Dec 12 07:45:58 2020 CET

Takže běžným používáním zapíšu za měsíc 3 GB

To je asi zcela mimo scope dotazu a použití v serveru. Ale 100MB za den? 12MB za hodinu, uvažujeme-li 8h provozu? Really?

[AraxoN]

SMART testy (short, long, offline a conveyance) spúšťame tiež, na striedačku každý týždeň.

Mám otázku k tomu checku poľa - to keď sme robili, rýchlo sa ukázalo, že check SW RAID-1 môže vykázať mismatch_count aj keď sú dáta celkom v poriadku. Je to známa "vada" (v skutočnosti optimalizácia) SW RAID-1, keď sa v rýchlom slede vytvorí a zmaže súbor, a na jednom disku sa zápis stihne vykonať, ale na druhom sa stornuje ešte pred vykonaním. Tým vzniknú rozdielne dáta na dvoch diskoch, čo v skutočnosti ničomu nevadí, pretože ide o voľné miesto z pohľadu súborového systému. Pri RAID-5 takéto falošné poplachy nevznikajú, tam zápis vždy dobehne, ak tomu správne rozumiem.

Čo sa týka času, za aký celý disk prečítame, a prečo je ten čas taký dlhý... Keďže to čítanie celkom vážne ovplyvňovalo iné činnosti na serveri, začali sme tento úkon škrtiť a preto nám prečítanie 2TB disku netrvá len 4 hodiny, ale niekoľkonásobne dlhšie. Bol to kompromis a s prechodom na väčšie disky tento kompromis narazil na svoju konečnú hranicu možností. Hľadáme teraz spôsob, ako to robiť inak.

[dustin]

Zajímavé. Další důvod používat filesystémy s integrovaným raidem (ZFS, BTRFS), které ví, co mají obsazené a volný prostor neřeší. Samozřejmě přechod z legacy instalací není snadný, také máme takových spoustu.

[AraxoN]

No áno, keď sa ignoruje voľný priestor, prebene to rýchlejšie. Ale stalo sa nám už, že disk mal vady práve v tom voľnom priestore a celkom prestal reagovať, kedykoľvek do toho voľného priestoru zablúdil, aby ho začal využívať. To sa nakoniec podarilo odhaliť tým čítaním cez dd a preto sme to tak začali preventívne robiť. Ale ako tak premýšľam, to bolo ešte v dobách PATA diskov. U SATA/SCSI/SAS diskov som asi takéto kompletné vytuhnutie ešte nevidel.

[AraxoN]

• Kde je btrfs, tak scrub.
• Kde je MD RAID, tak check/repair.
• Koukám na SMART.

[AraxoN]

Na Btrfs sme stále nenašli odvahu. MD RAID a Ext4 sú pre systémové súbory preverená kombinácia a tak sa jej držíme...

Ale na veľké dáta sme nedávno nasadili zopár Ceph clusterov a ak tomu správne rozumiem, tiež tam prebieha scrub, ktorý vo "voľnom čase" hľadá nekonzistencie. Scrub vyzerá ako cesta, ktorou sa dajú kontrolovať zapísané dáta aj vo väčších kapacitách.

Výstup z checku MD RAID kontrolujete ako, ak sa smiem spýtať? Priamo čítaním /sys/block/md?/md/mismatch_cnt alebo nejakým nástrojom? Čo falošné poplachy pri RAID-1, ako som písal vyššie?

[Jendа]

Ano, mismatch_cnt. Ano, falešné poplachy se bohužel vyskytují a nevím co s tím.

systémové súbory

Vidíš, ještě můžeš dělat debsums -c.

[AraxoN]

Ano, mismatch_cnt. Ano, falešné poplachy se bohužel vyskytují a nevím co s tím.

Falošné poplachy mismatch_cnt u SW RAID-1 sú jednoducho vlastnosť. Vzniká to, keď sa požadovaný zápis stane nadbytočným, ale jeden z diskov ho už stihol realizovať, ako som písal vyššie. Chvíľu sme to skúšali a nakoniec sme to používali len pre SW RAID-5 polia. Tie sme nedávno nahradili Ceph clustermi, takže MD RAID check už nepoužívame.

Vidíš, ještě můžeš dělat debsums -c.

Nie na Gentoo linuxe, obávam sa. :)

[AraxoN]

Jde samozřejmě o to, jak cenná jsou data, jak velká je úroveň redundance atd. V zásadě je Váš způsob velmi dobrý:

1. Při čtení si disk nemůže vymýšlet. Buď (alespoň na několik pokusů) přečte, nebo musí přiznat chybu.

2. dd na rozdíl třeba od offline SMART testů nevyžaduje, aby disk nic nedělal, proto na strojích, které nejsou kriticky zatíženy, lze často strpět test disku bez odstávky. Je možné tomu ddčkování nastavit nižší (io)prioritu, je možné testovat po nějakých blocích (seek), apod.

3. Těžko říct, zda existuje nějaký vhodný interval. Kontroly vždy přidělávají práci a obtěžují. Je vhodné nemít disky v prašném prostředí, nepřehřívat je, moc nevypínat, nepřekračovat odhadovanou živostnost, ale to jsou samozřejmosti. Ale stejně nikdo neví, kdy to disk vzdá.

[AraxoN]

Jde samozřejmě o to, jak cenná jsou data, jak velká je úroveň redundance atd. V zásadě je Váš způsob velmi dobrý:

Nuž, ako IT firma, ktorá okrem dát a ľudí nemá prakticky žiadne iné aktíva, dáta sú veľmi cenné.

Rovnako cenná je aj schopnosť preklenúť hardvérové poruchy bez dlhšieho narušenia prevádzky. Čo z toho, že má firma zálohu, ak obnovenie prevádzky z tej zálohy bude trvať viac ako týždeň? Taký výpadok môže byť likvidačný.

1. Při čtení si disk nemůže vymýšlet. Buď (alespoň na několik pokusů) přečte, nebo musí přiznat chybu.

Rovnako sme aj my uvažovali.

2. dd na rozdíl třeba od offline SMART testů nevyžaduje, aby disk nic nedělal, proto na strojích, které nejsou kriticky zatíženy, lze často strpět test disku bez odstávky. Je možné tomu ddčkování nastavit nižší (io)prioritu, je možné testovat po nějakých blocích (seek), apod.

I/O prioritu škrtíme už teraz, ale ten seek, to je niečo, nad čím rozmýšľam - keby sa namiesto jedného dlhého čítania celého disku od začiatku po koniec rozdelila táto operácia na kratšie úseky, dali by sa robiť samostatne, mimo špičky, každú noc, a než prejde mesiac, celý disk by sa prečítal takto. To nie je zlý nápad!

3. Těžko říct, zda existuje nějaký vhodný interval. Kontroly vždy přidělávají práci a obtěžují. Je vhodné nemít disky v prašném prostředí, nepřehřívat je, moc nevypínat, nepřekračovat odhadovanou živostnost, ale to jsou samozřejmosti. Ale stejně nikdo neví, kdy to disk vzdá.

Svätá pravda.

[Jendа]

1. Při čtení si disk nemůže vymýšlet. Buď (alespoň na několik pokusů) přečte, nebo musí přiznat chybu.

Rovnako sme aj my uvažovali.

Pššt, nebo přijde ten jehož jméno se nevyslovuje, vytáhne, že disk si data může vymyslet, a nebude mít žádnou analýzu jestli je to jeden bitflip, celý blok je nesmyslný a je to náhodná kolize CRC32, nebo je pokažených více bloků za sebou, ale děje se to, věřte mi.

[AraxoN]

Áno, vlastne áno, teraz keď hovoríš. Disk si vymýšľať môže, už som o takých prípadoch čítal. Ďalší plusový bod pre btrfs a Ceph, ktoré pre tieto diskové zrady majú riešenie.

[j]

jj .. by me fakt zajimalo, jak se takovej random bit propasuje z ty plotny, pres samoopravny kody a elektroniku disku az do ramky ...

Rek bych, ze s(temer) 100% jistotou skonci tam kde zacal - na opravitelny chybe cteni. Kteryzto vykazuje kazdej jeden disk. Ve skutecnositi bych rek, ze disk ve skutecnosti umi opravit vic nez jeden vadnej bit.

A jaka je asi tak pravdepodobnost, ze (kdyz uz to ten disk neumi opravit) to zaroven neumi ani detekovat (tzn neopravitelna chyba = badko). Skoro bych rek, ze zadna.

Mno a pak se dostanem k tomu, ze ale ten bit se ti muze prehodit i v ty ramce, coz se prece bezne deje, a proto vsichni denne ztraceji data ;D.

Jinak receno, btrfs urcite neni spatna vec, ale jestli ho hodlas resit kvuli prehozenym bitum na disku, tak ses zcela mimo.

BTW: Mam tu jeden takovej muzealni stroj, disk pravidelne loguje nejaky chybky synchronizace (asi vadnej kabl), ale data nakonec precte naprosto vpohode. Jak to sakra dela?

---

Dete s tim guuglem dopice!

[Peter Golis]

A jaka je asi tak pravdepodobnost, ze (kdyz uz to ten disk neumi opravit) to zaroven neumi ani detekovat (tzn neopravitelna chyba = badko). Skoro bych rek, ze zadna.

Niesom jediný, čo zažil že mu disk namiesto prečítaného dát vrátil blok prázdnych núl. Keby sa to nedialo aj ostatným, tak BTRFS, ZFS (a asi aj Hammer2 a ReFS) vypnú checksumming na dáta ak majú k dispozícii len jeden disk bez redundancie. Čítanie z disku by tak či tak vyhodilo I/O error, a proces by sa to tak dozvedel.

[AraxoN]

Svete sa div, máme súbory, ktoré sa nemenia, a máme k nim meta-údaje v databáze. Medzi meta-údajmi je aj hash súboru. Aké bolo moje prekvapenie, keď som po rokoch prevádzky len tak zo srandy nechal porovnať hash z databázy s hashom skutočných dát v súboroch? Vo viac než len jednom prípade to nesedelo.

Neviem bohužiaľ povedať naisto, či tieto chyby vznikli pri čítaní z disku, alebo niekde inde - v pamäti, pri prenose po sieti, pri migrácii zo starého železa na novšie. Ale silent data corruption sa deje a treba proti nemu bojovať.

[j]

A to te ani nenapadlo, ze presne takovy data trebas na disk zapsala tvoje aplikace? Nebo filesystem? Nebo cokoli dalsiho? Jak rikam, pravdepodobnost, ze k chybe dojde na urovni HW je naprosto miziva, a dost pochybuju, ze tu je clovek, kterej by se s takovou setkal.

Daleko pravdepodobnejsi je, ze se soubory zkurvi vejs, a s tim ti fs (kterej je muze zmrvit i sam) nijak nepomuze.

Ve skutecnosti sem Xkrat videl na vlastni oci stav, kdy aplikace zapsala neco jinyho, nez co videl uzivatel. Kterej se pochopitelne pri dalsim otevreni, z hlediska fs a disku zcela koretkniho, souboru nestacil divit.

Totez se ti muze stat pri presunech, kopirovani ... opet, z hlediska fs i disku bude ten soubor zcela koser, jen se lehce zmeni ... a i tohle sem videl.

Ve widlosvete se pak povazuje za "normalni" ze se do souboru hrabou trebas tzv "antiviry" a klidne si je menej. Jediny stesti, ze dneska uz teda prevazne neco jako "lecit" neumej a rovnou to mazou.

BTW: Za poslednich cca 15 let, sem se na radove desitkach TB ECC ramek nesetkal s tim, ze by nekdy nejaka zalogovala chybu. Toliko k tomu, jak je nezbytne nutny mit ECC.

---

Dete s tim guuglem dopice!

[Peter Golis]

Jak rikam, pravdepodobnost, ze k chybe dojde na urovni HW je naprosto miziva, a dost pochybuju, ze tu je clovek, kterej by se s takovou setkal.

Ehm, čo dodať. Ak si si to ešte nevšimol, tak to neznamená že sa to nestalo aj tebe. Mne sa to už stalo, a nebol som sám.

V opačnom prípade by neexistoval pojem Silent Data Corruption a CERN by o tom nenapísal štúdiu ktorej výsledky by nepotvrdil Amazon. Odporučím k tomu pozrieť aj výsledky kolektované firmou Greenplum alebo štúdie NetApp.

BTW to ECC na RAM odchytáva firmware dosky, a OS sa dozvie až keď nastane neopraviteľná chyba (ak sa doska pri takej chybe rovno nevypne). Takže by som odporučil skontrolovať log z ECC v UEFI cez remote kartu.

[Jendа]

Přesně jak píšu, to je ale škoda, že si někdo dá takovou práci a v případě toho CERNu investuje nemalé prostředky, a pak z toho nic není. Ten CERN už vůbec nejde najít (stránka konference rozbitá a ve wayback machine není) a ten NetApp vůbec neřeší nejen o jaké chyby jde (bitflip, kolize v CRC, nuly, nebo co), ale ani to, jestli jsou to data, která se podařilo korektně zapsat a pak třeba i přečíst a vyhnila časem, nebo kdy k chybě dochází, jestli když ten blok přečtu stokrát, tak dostanu různé výsledky. Naopak mají ve studii několik dost podezřelých věcí a vůbec bych se nedivil, kdyby se nakonec ukázalo, že to jsou race conditions v zápisu dat a checksumu v jejich software.

Observation 9 The probability of a disk developing a checksum mismatch is not independent of that of other disks in the same storage system.

Jasně, to úplně vypadá jako chyba disku. A je to nakažlivé.

Observation 13 Checksum mismatches correlate with system resets.

The conditional probability of a system reset at some point of time, given that one of the disks in the system has a checksum mismatch, is about 3.7 times the unconditional probability of a system reset. After a system reset, the system performs higher-level recovery operations; for example, a thorough file system integrity check may be run.

Jako že hnití magnetického záznamu na disku je způsobeno resety elektroniky?

[Peter Golis]

Automatické parkovanie hlavičiek nikdy poriadne nefungovalo. Takže pri resete tá hlava kľudne klepla o platňu, a škrkla ju. Následne sa začal ten škrkanec rozrastať,...

Inak podobné štatistické štúdie vydalo aj Google. Jednalo sa o štatistiky zlyhávania konzistencie dát a úmrtnosti diskov. Občas to rozbúrilo hladiny internetu.

[j]

Jako fakt?

"Čo z toho, že má firma zálohu, ak obnovenie prevádzky z tej zálohy bude trvať viac ako týždeň? Taký výpadok môže byť likvidačný."

???

Tohle myslis vazne? Takze zadny zalohy nemas, takhle to je treba chapat.

Adminuju firmu kde sem schopen (klidne vzdalene) previst provoz behem cca 15 minut na zalohu. Rucne. Protoze nejaky automatismy byly vyhodnoceny jako zcela zbytecny. Ve skutecnosti je vyhovujici cas do 4 hodin.

A presne s tim se zalohovani navrhuje a dimenzuje.

Pochopitelne to predpoklada odpovidajici SW i HW. Tzn ve zminenym pripade tam je sekundarni pole na ktery se dalaji snapy, a z libovolnyho snapu je pak mozny nastartovat cokoli. Samozrejme by to znamenalo nejakou ztratu dat (cca 15 minut). Nejsou to zadny kdyby, protoze se to uz jednou pri failu primarniho pole pouzilo.

Naptosto padly na hlavu mi prijde, pokud ma nekdo i jen desitky TB dat, a predstavuje si, jak bude odnekud po siti tyhle data nekam obnovovat ... lol. To pak je samozrejme na dny v lepsim pripade. I po desitkovy siti to da jen 1GB/s => cca 3,5TB za hodinu ... v idealnim pripade. A kolik zalohovacu ma desitkovou sit a kolik ma dost disku aby to 1GB/s dalo.

---

Dete s tim guuglem dopice!

[AraxoN]

Tohle myslis vazne? Takze zadny zalohy nemas, takhle to je treba chapat. ...

Komponenty sú samozrejme zdvojené a dáta replikované v rámci serverovne. Vypadne primárny databázový server? Prehodíme to na sekundárny. Vypadne jeden z aplikačných serverov? Spustíme aplikáciu na ďalšom serveri. Vypadne súborový server? Tam vlastne Ceph nemá nikde single point of failure, takže sa (z pohľadu aplikácií a používateľov) nič nestalo.

Čo ale vo chvíli, keď na serverovňu napadne kalamitné množstvo snehu a preborí strechu? Búdu fuč primárne aj sekundárne servery. Práve na to existuje záloha dát v inej lokalite, aby sa prevádzka dala obnoviť na novom železe. Tam je limitujúcim faktorom práve obstaranie nových databázových a aplikačných serverov, čo aj pri maximálnych kompromisoch neviem si predstaviť, že bude trvať kratšie než týždeň.

[j]

A tomuhle zabrani to, ze budes neustale cist data z disku abys zjistoval, jestli na nich neni badko?

O post vejs brecis, ze budes v pripade failu disku obnovovat zalohy tyden.

---

Dete s tim guuglem dopice!

[j]

A presne proto ze rozhodne na discich nepousteji silenosti ktery se je snazej cely cist a porad dokola. Od toho tam mas ten raid, aby pripadny selhani zachytil.

Zkus si to predstavit, koupis si (za 7+ nul) hromadu disku, a 90% jejich vykonu sezeres tim, ze budes zjistovat, jestli na nich nedej boze neni nekde badko? Proto je tam ten raid. Az se na to badko narazi, tak ho raid vyresi a disk vyradi. Tecka.

Muzes tu argumentovat miliardou jinych chyb, od cehoz jsou prozmenu zalohy.

Me by zajimalo, jestli se tu najde nekdo dost ynteligenti, kdo nez vyrazi k mori, nejdriv nejezdi ty +-2 tisice km kolem baraku, aby overil, ze to auto k tomu mori (a potazmo zpet) dojede ... a to pokazdy, nez nekam vyrazi.

Typicky pole se chova tak, ze novy disk cely precte (aby overilo ze je OK) a pak na nej naladuje data. Nasledne sleduje chyby cteni (opravitelny) a pokud jejich pocet stoupne nad uroven nebezpecnou pro zdravi, tak disk vyradi.

Disk je spotrebni zbozi, a presne tak je treba se na nej divat. Proste driv nebo pozdejs umre, tak vytahnes ze suplete nahradni a vymenis ho. Tim cela operace konci.

---

Dete s tim guuglem dopice!

[vandrovnik]

Pravidelné long testy přes SMART rozhodně spouštíme, protože dost dat na discích se u nás skoro nikdy nečte (staré maily, archiv fotek a dokumentů apod.), takže bez testování by se na případné vadné sektory přišlo za xx let, až by někdo ten soubor konečně potřeboval.

Jestli u vás test disku sebere 90 % výkonu, tak je něco špatně, ne? I kdyby se ten test pouštěl jednou týdně a i kdyby běžel 10 hodin, tak je to 10 hodin ze 168, kdy disk bude podávat horší výkon, zbytek jede normálně. No a nemám-li provoz 24x7, tak samozřejmě test se spouští tak, aby proběhl přes noc, kdy to nevadí nikomu, a testuje se vždy jen jeden disk z pole, takže ostatní fungují normálně.

Nevím, jak moc je mdraid chytrý, aby posílal požadavky na čtení přednostně na zařízení, které mu dává odpovědi rychleji, zrovna tak nevím, jak moc jsou chytré disky, aby si všimly, že dostávají hodně požadavků a mají je upřednostnit před SMART testem - nikdy jsme nenarazili na to, že by vzniklo znatelné zdržení, tak nebylo třeba to zkoumat.

[AraxoN]

Zdravim
Spustim:

pv /dev/sdX > /dev/null

Pustim vecer a rano mrknu zda se povedlo veskera data na disku precist. Totiz SMART porad tvrdi ze PASSED ale pak narazim na disky ktery proste v urcitych oblastech nejdou precist, rychlost klesne radove na kB/s a pak cteni skonci OI errorem. Na takoveto necitelne disky je vsak mozne (samozrejme destruktivne vuci obsahu) zapsat data z /dev/zero Pri moji praxi se jedna hlavne o disky 2.5" o kapacite 1TB.

[Josef Kufner]

BTRFS Scrub dělá přesně to samé. Prostě jen přečte všechna data a když se to někde nepovede, tak dostanou příležitost opravné mechanismy a můžou například využít kopii na druhém disku v RAID1.

[Jendа]

btrfs scrub je „něco víc“, kromě přečtení kontroluje i checksum (svoji vlastní). Takže odhalí třeba vadnou paměť v řadiči nebo v cache disku.

[Josef Kufner]

A nedělá to BTRFS standardně při každém čtení?

[Jendа]

Jo, to jo. Ale může být složité přečíst celý btrfs, protože data jsou různé poschovávaná a duplikovaná kvůli snapshotům a CoW. Navíc scrub se snaží číst co nejvíc sekvenčně, aby to bylo rychlejší než find / | xargs cat.

[AraxoN]

Dobre, zdá sa, že táto diskusia sklzáva do oblasti, ktorá už nie je produktívna. Ďakujem všetkým za Vaše kolektívne vedomosti a skúsenosti.

[AraxoN]

…cez príkaz dd…

Tohle podivné a zbytečné používání dd místo pv nebo cat mi přijde malinko úsměvné. No, co už.

…či sa nezhoršili niektoré vybrané SMART parametre.

Mně se například žádné parametry nezhoršily, jenom se najednou z počítače ozval zvuk podobný broušení a obrábění, z disku se vyvalila náhodná data (která Btrfs bravurně ustál a „opravil“ (tedy, neměl je jak zapsat zpátky na původní disk, to už nešlo a došlo na to až po výměně disku, ale aspoň vůči čtenářům je opravil)) a po odpojení a opětovném připojení disku už o něm nebylo na sběrnici SATA ani vidu ani slechu; asi se někam schoval.

S.M.A.R.T. předtím nehlásil NIC. Fakt nic. Reallocated_Sector_Ct byl 0 atd. No, disk jsem vyměnil a život šel dál.

Je pokus o testovanie disku čítaním celého jeho povrchu zbytočný overkill?

Podle mě ne. Je to dobrý experiment. Ale spíš než na S.M.A.R.T. bych se soustředil na to, jak dlouho čtení trvá a jak se během něj mění throughput. Očekávaný průběh je nějaká konkávní parabola, kdy je to ze začátku (vnější okraj disku) velmi rychlé a postupně se to zpomalí tak na 2/3 až 3/4 maxima (vnitřní okraj). Pokud tam jsou nějaké výpadky typu 1 MB/s po dobu několika (se)kund nebo minut (!) a pak zase návrat do normálu, je dobré o tom vědět. Jinými slovy, může se hodit nastavit například pv tak, aby zapisoval rychlost čtení každou (se)kundu někam do souboru, a pak to celé nějak vyhovnotit.

A sorry jako, čtení 8 TB netrvá celý víkend. Na 8TB disku (což je celkem malý disk, třeba ve srovnání s těmi 18TB novinkami), i kdyby byl průměr jenom 100 MB/s, vyjde přečtení celého disku na 80000 (se)kund, což je pořád méně než 86400 (se)kund za den. Takže ne, netrvá to celý víkend. A pokud jo, může být disk kandidátem na vyhození. (Nebo je fakt hodně vytížený.)

Jednou z možností by bylo přečíst každý víkend během nějaké klidné noci 10% toho disku. Další týden dalších 10% atd. A sledovat, jestli to odpovídá ostatním diskům (a LBA), co do rychlosti. Každých 10 týdnů by tak disk byl kompletně přečtený, v rámci téhle kontroly, ale nenakumulovalo by se to všechno na jeden jediný den.

[AraxoN]

Ďakujem za názor. Áno, SMART predikuje len zhruba okolo 50% prípadov zlyhania diskov. Presné číslo si nepamätám, niekde na to bola štúdia. Aj 50% je výrazným zlepšením oproti 0%.

Čo sa týka rýchlosti čítania, že 8TB disk číta týždeň, to bol len odhad v našom prípade, na základe rýchlosti, akou sme predtým čítali 2TB disky:

Done /dev/sdc - 1863.0GB in 130585 seconds

Prečo tak pomaly? Lebo ten disk musí robiť aj iné veci, takže toto "preventívne" čítanie má u nás najnižšiu možnú prioritu.

[alkoholik]

Na tohle se bere vetsi kladivo. Disk do RAIDu a nastavit smartctl -l scterc,30,30 /dev/sdX.

[lertimir]

Já tu ideu se smart parametry trochu chápu, ale je to něco, co jsem dělal tak před 10+ lety. Seagate v parametru Raw_Read_Error_Rate píše raw data kolik opravitelných chyb dělá. Takže jsem nový disk podrobil kontinuálnímu čtení a tento parametr snímal v pravidelných časových intervalech a počital difference, a z grafu bylo vidět jak se rychlost nárustu chyb mění v rúzných částech disku. Interpretoval jsem to jako kvalitu povrchu a pokud byla na mnoha místech výrazně vysoká disk jsem vracel. Ale myslím že s přechodem na 4K sektorové disky a se zmenšením velikosti buněk, kdy se začínají projevovat kvantové jevy to již není vypovídající informace.

[j]

" i kdyby byl průměr jenom 100 MB/s,"

Tvle, ty ses z Marsu? Tohle neda za provozu naprosto zadnej mechanickej disk, takovej jeste nikdo nevyrobil. Tohle jsou ciste hypoteticky cisla pri linearnim cteni s naprosto nulovou zatezi. Totez samozrejme plati o sledovani rychlosti ... vypadky jsou uplne normalni, protoze disk ma velice omezeny IOps a pokud se vycerpaji, tak mu jaksi nezbejva, nez delat co muze = seekovat.

Takze vikend na 8TB je naopak hodnota velice solidni vypovidajici o mizivy zatezi.

Zatizenej disk ty tatare neda ani 10MB/s. Mam tu 15tidiskovy velice zatizeny pole, ktery setrvale jede vicemene na full a vis kolik tech 15 disku da dohromady kdyz z nej neco budu za provozu chtit cist? 20MB/s je strop. Takze +- ani ne 1,5MB/s per disk.

---

Dete s tim guuglem dopice!

[AraxoN]

Kontrolujete pravidelne svoje rotačné disky?

Ano.

Ak áno - ako?

SMART short testy každý den. SMART long testy každý týden. BTRFS scrub každý týden. ZFS dtto.

My sme zatiaľ robili kontroly mesačne, takým spôsobom, že sme fyzické disky nechali cez príkaz dd prečítať od začiatku po koniec a potom sledovali, či sa nezhoršili niektoré vybrané SMART parametre.

To je rozhodně zajímavý přístup, ale smart parametry patří do monitoringu + nastavit si ve smartd.conf posílání emailů.

Obecně k "ručnímu" čtení celých disků nevidím důvod. Od toho jsou technologie, které dokážou buď automaticky (smart testy), nebo si umí poradit i s případným problémem (scrub). Nebo v nejhorším jen oznámit nekonzistenci (mdadm check)

A teraz prechádzame na 8TB disky, kde by prečítanie celého disku trvalo týždeň a to by kolidovalo s normálnou prevádzkou.

To mi nevycházda. Vůbec se zde v diskusi vyskytují zajímavé počty.

[AraxoN]

Ďakujem.

SMART hodnoty zbierame v skutočnosti monitoringom každých 5 minút, ale nechcel som pôvodný dotaz príliš komplikovať.

Aj to použitie dd je len príklad, v skutočnosti na to používame interne vyvinutý tool, ktorý číta celý disk, ako by to robil dd, ale rýchlosť čítania obmedzuje podľa nejakých ďalších parametrov, aby nepreťažoval I/O. Preto nedá 8TB disk za deň. Ten disk by to síce zvládol, ale klienti a zamestnanci by nás medzitým zožrali.

[Peter Golis]

Jéj, to je veľmi pekné riešenie. Používate IONICE na jednoduché zníženie priority čítania alebo to detekujete podľa iných parametrov a sami obmedzujete rýchlosť?

[AraxoN]

Začalo to s dd, potom sa prešlo na ionice -c 3 dd, ale aj to bolo príliš invazívne v niektorých vyťažených momentoch, takže sme sa potom rozhodli nakódovať vlastné riešenie.