Patálie z diskem

14.3.2015 21:04 | Přečteno: 1240× | Linuxové drobty | poslední úprava: 20.3.2015 15:34

Patálie z diskem začala ve středu, systém se začal trochu zasekávat. Prohlídkou smart tabulek zjištěny chyby čtení a nahozený short smart test nedojel. Vzhledem k tomu, že to byl 3TB Seagate v domácím kompu tak nalezení dostatečného prostoru pro nějakou záchranu dat bylo trochu dramatické. (disk má obsahuje sice zajímavé, ale v jádru postradatelné informace. jejich cena není na úrovni druhého záložního disku.) Na disku byly dva podstatné oddíly:

1. swap - protože systémový disk je SSD a tím pádem jsem jej nechtěl trápit vysokými zápisy a volil jsem raději HDD pro něj.
2. hlavní datový oddíl přes 2,5T naformátovaný na xfs. Pak ještě malé reziduum v malém ntfs oddílu

Restaurace probíhala přes ddrescue do vytvořeného volného prostoru, a měl jedno specifikum a to že jsem potřeboval rychle nebo nic. důvod byl ten že disk je jjiž po standardní záruce od prodejce, ale měl Seagate záruku a ta končila dnes, tedy 4 dny po začátku problému (uznávám, že je to klika, stejně mohla skončit o 4 dny před začátkem problému) chyby zatím nebyly závažné a ddrescue měl cca 6,5 MB nepřečtených sektorů z 2,5 TB. Překvapivé pak bylo, že xfs_repair měl s opravou problémy. Nutno říci, že ve středu po identifikaci chyby nebylo možné systém korektně vypnout. Patrně nebylo možné napsat na XFS korektní log a proto odpojení nešlo. po ddrescue kopii nebylo možé fs moutnout a ani přimo opravit a nešlo pokročit jinak než smazáním logu. při xfs_repair. což spůsobilo poměrně masivní přenosy do lost+found xfs oddílu celkem přes 500GB dat což je na 6MB chybu dle mne hodně. (jsem si věnom že značná část bude díky chybějícímu logu, na oddíl se psalo v době pádu.)

Závěr pokud uvažuje provozovat HW bez jištění (RAID, UPS) zvolte jiný FS než XFS. XFS je sice mnohdy velmi efektivní a výkonné, zvláště s velkými soubory, ale vysoce citlivé na spolehlivost HW na kterém běží. ext4 by takovou velkou chybu neměl.

Veškeré opravy jsem v tuhle chvíli dělal z systemrescuecd. Zachránil jsem co rozumě šlo a disk odeslal do Mnichova. ale bylo mé velké překvapení, že systém odpojení disku nenajel. Přirozeně jsem smazal položku týkající se swapu v fstab a stajně tak položku týkající se resume v volbě jádra v grubu. Přesto systém nenajel a skončil v dracut shellu s tím, že neumí najít resume oddíl se swapem. Vytvoření nového oddílu nepomohlo a jediné, co systém znovu udělalo funkční, bylo přegenerování initramfs. Update zápisku. 20.3. Přesně týden po odeslání se mi v mailu objevilo od UPS, že převzalo od Seagate nový disk (a 19.3. Seagate poslal, že disk odesílá včetně nového seriového čísla)        

Komentáře

[Josef Kufner]

Když mi toto začne disk dělat, udělám jen remount do read-only, pokud je místo, začnu kopírovat okamžitě (na úrovni souborů), pokud není, tak dojdu pro nový disk a zkopíruju jakmile se vrátím. Žádné vypínání nebo odpojování. Prostě jen přestat používat a nechat točit. Nejlépe zastavit jakoukoliv diskovou aktivitu, aby se nevypláchla disková cache. Je docela fajn, že SATA je hotswap a není potřeba počítač vypínat.

[R]

Presne tak, dolezite veci kopirovat hned a po suboroch. Ked je na tom disk naozaj zle, tak po vypnuti sa uz nemusi rozbehnut alebo filesystem nepojde namountovat. A dd_rescue ho moze dorazit - videl som: najprv sa kopirovanie rozbehlo, ale potom sa dostalo na vadnu oblast, disk zacal realokovat velke mnozstvo sektorov az vsetky "nahradne" vycerpal. Tento stav asi nebol vo firmware korektne osetreny, tak disk prestal reagovat a po vypnuti uz nefungoval vobec...

[Pavel Píša]

Pokud je kam kopírovat, třeba i po lokální síti, tak je strategie nevypínat dobrá.

Na druhou stranu jsem několikrát uspěl s ddrescue na disku, který při najetí do chybové oblasti kolaboval tak, že potřeboval pro reset vypnout napájení. ddrescue pak běželo dny, s tím, že jsem se vždy u počítače stavil, zkrátil označení nepřístupných oblasti a pustil ddrescue v opačném směru (od začátku, od konce).

Další věc, co pomohla zvýšit citlivost a dostat se k datům z mnoha chybných oblastí je snížení šumu elektroniky podchlazením disku. Nechal jsem dobře/těsně zabalený disk přes noc v chladničce (později možná dokonce i v mrazáku) a pak ho zabalil aby se ohříval pouze pomalu a tak jsem z něho dostal další data.

U jiného disky, který na tom nebyl tak špatně podchlazení pomohlo k přečtení všech dat.

Úspěch/nepoškození disku podchlazením v žádném případě negarantuji, ale statisticky mi již několikrát velmi pomohlo.

[Josef Kufner]

Nevypínat a kopírovat je vhodná strategie na začátku, když je selhání disku zjištěno, nebo ještě lépe, když disk teprve začíná zlobit. Pokud se část dat nepovede přečíst a není tato část zálohována, pak přijde na řadu mrazák a ddrescue. Tedy bavíme se o dvou nezávislých fázích záchrany dat z disku.

[Nicky726]

Přesto systém nenajel a skončil v dracut shellu s tím, že neumí najít resume oddíl se swapem. Vytvoření nového oddílu nepomohlo a jediné co systám znovu udělalo funkční bylo přegenerování initramfs.

Máš tedy nakonfigurovanou hibernaci. Jednak jde o resume háček v mkinitcpio.conf (nebo jak to tvá distribuce řeší), kterým se volba nastavuje, a pak o resume parametr jádra v konfiguraci zavaděče. Myslím, že by mělo stačit vyhodit tento z konfigurace zavaděče.

[bogo]

ext4 by takovou velkou chybu neměl.

Mas nejaky dukaz, nebo varis z vody ?

[lertimir]

Zachraňoval jsem data s jiného disku s ext4, kde chybovost sektorů byla po ddrescue přibližně 0,8% a struktura byla méně narušená než v tomto připadě kdy bylo nečitelných 7MB z 3TB tedy 0,00023%. Podrobnější studii nemám. Ale mnohdy jsou s XFS problémy i po HW výpadku napájení, beru ho jako výkonný systém pro spolehlivý HW.