Hianyzo blokk

Naplózó filerendszerek (journaling)

Udv!

Akadt egy HW- hibam a jelen laptoprol irt vinyomon. Eloszor a grub nem bootolt be, es ez maradt is, de boot cd- rol bebootolva azt tapasztaltam, hogy az sda1 particiom masodik 4K- s blokkja nem olvashato, az osszes tobbi igen (legalabbis az elso 1 gigaban). Az egesz particiora a cfdisk azt mondja, hogy 57529.08 MB nagy, ezenkivul csak egy extended swap particio van sda5 neven 2479.89 merettel (miert ilyen nagy?).

Nos, a kerdesem az lenne, hogy az adataimat hogyan tudnam errol a vinyorol megmenteni. Az elso 4K- s blokkot le tudom menteni, es a 3. 4K- s blokktol is mindent, de mi a helyzet a masodik blokkal? Ext3- rol van szo, nem ismerem a fajlrendszer felepiteset, de feltetelezem ennyire az elejen meg metaadatok vannak, vagy valami hasonlo, ami nagyon kell :- ).

Koszi a valaszokat!

  • 8270 megtekintés

( locsemege v | 2013. 08. 03., szo – 00:03 )

Mielőtt bármit tennél, az egész diskről kellene egy szektoros másolatot csinálni dd_rescue paranccsal.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( elod v | 2013. 08. 03., szo – 11:41 )

#1 - ne pánikolj

#2 ddrescue (szigorúan a GNU project-től) és dd_rescue ha van hova. Egy backup nem backup.

#3 megkeresed az alternatív superblokkokat és mountolod egyikkel

Nem panikolok, van mentesem, bar azert nem eppen csutortok esti.

Jelenleg fut dd- vel a mentes, mar 49GB- nel jar. Eloszor lementettem az elso 4K- t, utana pedig 

dd if=/dev/sda1 bs=8K skip=1

. Azt hittem a 8K- s blokkmeret miatt iszonyu lassu lesz, de ez a 49GB kb. 32 perc alatt jott at. Remelem a maradek is gond nelkul atjon. Ha kesz, csinalok egyet dd_rescue- val is, csak olyat meg nem hasznaltam. Jelenleg ez a 2 filem van: 


-rw-rw-r-- 1 guest guest        4096 Aug  3 12:10 dd_4096ig
-rw-rw-r-- 1 guest guest 54155419648 Aug  3 12:45 dd_8192tol

#3. No errol tudnal nekem picit tobbet meselni? Hogyan tudom megkeresni?

Érdekelne, hogy mi a probléma a dd_rescue-val a ddrescue-hoz képest. Mindkettőt sikerrel alkalmaztam már. Persze ha haldokló szektorok vannak, akkor mind a kettő lassan megy. Vigyázni kell a sparse opciókkal. Dehát a paraméterezésnél mind a kettőnél figyelni kell.
Az egyetlen, ami nekem eddig nem jött be a dd_rescue-nál, az hogy a visszatérési érték miatt sikeres másolás végén nem megy tovább a parancssor && után. Bár lehet, hogy erre is van egy opciója, amit nem ismerek...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( fn26 | 2013. 08. 03., szo – 19:42 )

Nos, csinaltam par mentes, es az egyik dd_rescue- sra raengedtem egy e2fsck- t. Egesz szepen lefutott, es latom is a fajljaimat, viszont a vinyon magan ez nem mukodik: 


e2fsck: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda1
Could this be a zero-length partition?

. Mint ismert, csak a masodik 4K- s blokkom hibas. Hogyan lehetne elerni, hogy ezt ne hasznalja, es kozben javitsa meg a dolgokat?

Feltetelezem a dd_rescue az emlitett hibas 4K- s blokkot feltoltotte 0- kkal, es az e2fsck ezt megjavitotta, felulirta, de a valos vinyon ez nem lehetseges, mivel az nem olvashato (es nyilvan nem is olvashato).

Valakinel valami otlet erre nezve?

Te is megteheted ugyanezt dd-vel, de először nagyon biztos lennék benne, hogy megvan minden.
dd if=/dev/zero of=/dev/sdaX
Jól paraméterezett bs, seek és count opcióval felülírod azt a részt, normális esetben ha tényleg hibás akkor a lemez belsőleg reallokál.

Biztos egy teljes 4K-s blokk (tehát 8 szektor klasszikus lemezen, ahol ugye a bs=512) hibás? smartctl -a /dev/sda ezt hogy jeleníti meg?

dd_rescue alapbol 512- es blokkokat hasznalt, es az elejen 8 hibat dobott, illetve amikor kezzel (dd- vel) probaltam meg kiolvasni, akkor is ugyanerre jutottam, igaz 1K- s blokkokat hasznaltam.

Mint lejjebb irtam, jelenleg megoldodott, de nagyon nem tudom, hogy jol csinaltam- e, es azt sem, hogy valami akar- e arra a 2. 4K- s blokkra irni.


e2fsck /dev/sda1 -b 32768
e2fsck 1.42.4
Superblock need_recovery flag is clear, but journal has data.
Recovery flag not set in backup superblock, so running journal anyway.
/dev/sda1: recovering journal
Truncating orphaned inode 3279833 (uid=1000, gid=1000, mode=0100644, size=114011)

. Ennek lefutasa utan bebootolt. A man page- ben olvastam errol a -b- rol, bar van arra valami garancia, hogy azt a bizonyos 2. 4K- s blokkot ezutan sem fogja hasznalni akarni?

A garancia az ha a lemezt arra kötelezed hogy kijavítsa azokat a blokkokat.

Ha a dd továbbra sem tudja őket olvasni, írd meg őket zérókkal. Újraíráskor, amennyiben tényleg rosszak a szektorok a lemez át fogja őket irányítani a tartalékra.

smartctl -a /dev/sda-t továbbra sem kaptunk...

Amit csinálsz, az szerintem életveszélyes. Volt egy csúnya adatvesztésed, mert a HDD egy része sérült. Sikerült a mentett image-ből az adataidat visszanyerned, és most azon tanakodsz, hogy a sérült, rossz HDD-n ezt hogyan érhetnéd el?

Én örülnék neki, hogy az adataim megmenekültek, egy új HDD-re kiírnám őket, a régit teleírnám vagy 0-kkal, vagy random értékekkel, aztán kidobnám.

Amit elod írt, az logikus, jónak tűnik, ugyanakkor én nem bíznék egy olyan HDD-ben, amelynek volt olyan része, ami olvashatatlanná vált. Most lehet, hogy rá tudod venni annak a 8 szektornak a reallokálására - lehet, hogy fizikailag 4 kB-os szektorai vannak, s akkor ez csak 1 nagy szektor -, viszont jó eséllyel hamarosan megjelenik a következő olvashatatlan 4 kB, ezek elszaporodnak, az adataidnak búcsút mondhatsz.

Inkább örülj annak, hogy a dd_rescue-val másolt image-ből sikerült visszaállítani a file-jaidat, s ne azon törd a fejed, hogyan veszítheted el őket végleg.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Több ilyen lemezzel volt dolgom, ebből egyetlen egy ment meg úgy, hogy most már teljesen tropa (mivel olyan iramban szaporodtak). Laptop lemezeknél jobb a túlélési arány :)

Backupja van egyébként. Nem naprakész, de nem is túl régi ha jól emlékszem (vagy nincs, mert épp nem találom a témában :) )...

Az adatok visszahozatala igazabol a kisebbik dolog volt. Az utolso mentesemet 1 nappal azelott keszitettem, hogy kulfoldre jottem ujra, szoval max. bongeszesi elozmenyeket veszitettem volna. Amugyis kb. heti egyszer kapcsolom be, szoval olyan sok dolog nincs, inkabb csak nem akarok uj vinyot venni, es annak a beallitasaval szorakozni. Amugy igen, az adatok most teljesen le vannak mentve ujra, szoval a vinyon ha valami ujra tonkre is megy, nem lesz nagy gond, bar egyetertek amugy a hozzaszolasoddal, hogy normal hasznalat mellett nem kene ezt eroltetni.

Nem sok HW hibaval talalkoztam eddig, de tok erdekesnek talaltam, hogy egy szektor elvesztese mekkora problemat okoz, es mennyire jo ez az ext3, hogy bar vezerloszektor, megis ezekkel a backup szektorokkal adatvesztes nelkul atveszelheto volt minden - ha tudtam volna, hogy mi merre mennyi, akkor 10 perc alatt is akar.

Ha van backup, akkor megoldás lehet az is, hogy megfelelő opciókkal újra formázod a filerendszert. Azt mondja a manual, hogy -c-vel read-only, míg -cc-vel read-write tesztet csinál formázáskor. Ekkor vagy a HDD reallokálja a hibás szektorokat, s az oprendszer felé nem lesz hibás szektor, vagy, ha nem tud már reallokálni, akkor hibás szektorként bejegyzi az oprendszer a területet, s messzire el fogja kerülni.

       -c     Check the device for bad blocks before creating the file system.
              If this option is specified twice, then a slower read-write test
              is used instead of a fast read-only test.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE