Chyba disku vs. chyba souborového systému

[uwe.filter]

Taky bych zkusil disk vyndat z rámečku a připojit přímo přes SATA, pak už asi bude jasno. Jinak ještě poznámka k destruktivnímu testu přes badblocks - pokud se dobře pamatuju (kdyžtak mě někdo opravte), tak takový test nemusí sám o sobě odhalit vadné sektory. Jde o to, že pokud jich nebude moc, tak zápisem do vadného sektoru dojde k jeho přealokování diskem a navenek se to z hlediska procesu, který zapisuje (badblocks) bude jevit tak, že všechno proběhlo OK. Jinak se to navenek projeví pouze zvýšením hodnoty SMART atributu "reallocated sectors count", takže tu je dobré si případně před takovým testem někam poznamenat a pak porovnat s hodnotou po testu.

[Reklama]

[František Ryšánek]

Jinak ještě poznámka k destruktivnímu testu přes badblocks - pokud se dobře pamatuju (kdyžtak mě někdo opravte), tak takový test nemusí sám o sobě odhalit vadné sektory. Jde o to, že pokud jich nebude moc, tak zápisem do vadného sektoru dojde k jeho přealokování diskem a navenek se to z hlediska procesu, který zapisuje (badblocks) bude jevit tak, že všechno proběhlo OK. Jinak se to navenek projeví pouze zvýšením hodnoty SMART atributu "reallocated sectors count", takže tu je dobré si případně před takovým testem někam poznamenat a pak porovnat s hodnotou po testu.

Zhruba souhlasím :-) a taky to nevím přesně a podrobně.

Pokud disk při čtení narazí na sektor, který fakt nepřečte, tak podle mého vrátí řadiči (HBA) chybu média, ale může "pro příští použití" ten sektor realokovat - tzn. přibyde reallocated sector count i offline uncorrectable?

Pokud "ho přečte ale" tak má šanci ho realokovat potichu, přibyde jenom reallocated sector count.

Při zápisu mi není jasné, jak by disk mohl zjistit vadný sektor, když ho zapisuje (leda by zapsaná data vzápětí verifikoval, což IMO nedělá, nebo by ho zkusil předem přečíst, což taky nedělá - už proto, že by mu taková zápisová operace zabrala dvě otáčky.) Zjistit vadný sektor může při zápisu snad jedině tak, že není schopen ani navést hlavu na stopu (seek error / track not found). Navádění na stopu se totiž děje pomocí nějakých režijních značek, které jsou na plotně vyrobeny ve fabrice a za normálních okolností prakticky nezničitelné, resp. mnohem odolnější, než záznam užitečných dat vlastní hlavou. V tom případě by disk mohl při zápisu realokovat - celou stopu (všechny sektory na postižené stopě). Ovšem nakolik toto v praxi potkáte jako "gracefully" odstíněný problém, o tom mám svoje pochybnosti, protože nenalezení stopy obvykle znamená "vidím disk mrzutý, jehož hlava plotny se dotýká" - takže u takového disku rychle řešíte jiné věci, než pár realokovaných sektorů.

[wakatana]

Disk som teda vybral z externeho ramceka (nemal ventilator) a zapojil cez SATA na dosku. Dokazal som aj mountnut/umountnut NTFS particu. Spustil som nad nim nasledujuce prikazy:

Kód: [Vybrat]

badblocks -snv /dev/sda -o 2TB_SAMSUNG_BADBLOCKS.log
while true; do iostat -x sda | grep sda; sleep 10 >> iostat.log; done
Vysledok po cca 6 hodinach:
badblock vyzera ze zastal
disk uz nevidim ani pod lsblk (to iste sa mi stalo predtym ked bol v USB)
badblocks log vytvoril subor s chybami ktory ma 11GB!
iostat.log ma 460 riadkov a, teda to bezalo cca 72 minut kym to prestalo zapisovat
dmesg je plny podobnych chyb (3053 riadkov a to sa tam zrejme kopa ani nevosla)

Kód: [Vybrat]

[ 9368.765682] buffer_io_error: 2057516 callbacks suppressed
[ 9368.765684] Buffer I/O error on dev sda, logical block 279133313, async page read
[ 9368.765797] Buffer I/O error on dev sda, logical block 279133313, async page read
[ 9368.765903] Buffer I/O error on dev sda, logical block 279133313, async page read
[ 9368.766009] Buffer I/O error on dev sda, logical block 279133314, async page read
[ 9368.766114] Buffer I/O error on dev sda, logical block 279133314, async page read
[ 9368.766228] Buffer I/O error on dev sda, logical block 279133314, async page read
[ 9368.766332] Buffer I/O error on dev sda, logical block 279133314, async page read
[ 9368.766434] Buffer I/O error on dev sda, logical block 279133315, async page read
[ 9368.766533] Buffer I/O error on dev sda, logical block 279133315, async page read
[ 9368.766632] Buffer I/O error on dev sda, logical block 279133315, async page read


Myslite ze ma zmysel este nieco skusat, alebo mozem disk oficialne vyhlasit za mrtvy?
Nechapem ako je mozne ze SMART nehlasil ziadne realokovane sektory, a aj to ze som bol schopny spravit kopiu 1:1 cez ddrescue. Vyzera to ze disk sa zosype po tom co sa nan zacne zapisovat (podobny scenar tu bol spominany).

Mam teraz hlavu v smutku, lebo mam este jeden rovnaky 5TB disk s datami, na ktorom som si sice problemy nevsimol, no po tychto skusenostiach by som z neho data najradsej dostal co najskor niekde inde. Neviem vsak ci cez USB alebo ho pripojit na SATA alebo pouzit ddrescue (nemam na to momentalne miesto) ...

iostat.log http://paste.debian.net/1183172

Dakujem

[wakatana]

Myslite ze ma zmysel este nieco skusat, alebo mozem disk oficialne vyhlasit za mrtvy?
Nechapem ako je mozne ze SMART nehlasil ziadne realokovane sektory, a aj to ze som bol schopny spravit kopiu 1:1 cez ddrescue. Vyzera to ze disk sa zosype po tom co sa nan zacne zapisovat (podobny scenar tu bol spominany).

Este jeden dodatok. Po restarte je disk opat viditelny v Linuxe. Skusil som spustit Long Generic Test pod SeaTools Bootable, co je oficialna utilita od Seagate https://www.seagate.com/support/kb/how-to-use-seatools-bootable-007843en/ a test prebehol bez chyb, tak naozaj neviem co si o tom mysliet, ci proste ignorovat badblocks alebo co.

Este mam v plane:
1. spominany hddtest
2. prepisanie disku 0
3. format disku ako ZFS resp BTRFS a spustenie scrub

[wakatana]

Este ma napadlo ci by nebolo mozne podla error logu z badblocks skusat citat jednotlive sektory a pozerat do dmesg ci disk nehlasi nejake chyby? Myslim ze by to mohlo ist cez dd len si niesom isty spravnym nastavenim parametrov a matematikou ktora je za blokmi/sektormi.

Tu bolo nieco spomenute len som nepochopil ako sa dospelo k tymto cislam

BTW, chcete-li prověřit, zda Váš linux o tu adresu 0x0FFFFFFF zakopne, zkuste třeba něco jako
dd if=/dev/sda of=/dev/null bs=512 count=10 skip=268435450

Vdaka

[Reklama]

[František Ryšánek]

Este ma napadlo ci by nebolo mozne podla error logu z badblocks skusat citat jednotlive sektory a pozerat do dmesg ci disk nehlasi nejake chyby? Myslim ze by to mohlo ist cez dd len si niesom isty spravnym nastavenim parametrov a matematikou ktora je za blokmi/sektormi.

Tu bolo nieco spomenute len som nepochopil ako sa dospelo k tymto cislam

BTW, chcete-li prověřit, zda Váš linux o tu adresu 0x0FFFFFFF zakopne, zkuste třeba něco jako
dd if=/dev/sda of=/dev/null bs=512 count=10 skip=268435450

Vdaka

2 TB děleno 512B/sektor je asi 4 miliardy sektorů.
V mém příkladu s DDčkem tomu odpovídá argument bs=512 (block size = 512 B).
V této jednotce jsou číslované sektory v chybových hláškách v dmesg
(LBA adresace) - čísla sektorů jsou udávána v desítkové soustavě.

Ohledně toho starého bugu 0x0FFFFFFF hexa
= 00001111 11111111 11111111 11111111 binárně
= 268435455 desítkově .