Administrace komentářů

Já si myslím, že taková speciální věc je neexistence fsck na ZFS (a obdobně pro btrfs, kde fsck sice existuje, ale je ve stavu "do not use")

Tuhle přihlouplou a stokrát vyvrácenou pověru o fsck hodláš opakovat ještě dlouho?

Hele, to je ale zajímavé, že někomu tohle docvakne už koncem nultých let, na základě dokumentace k ZFS a (ranému) Btrfs, zatímco někomu jinému to ještě o 15 let později … ehm … působí nejasnosti. Inu, každý svým tempem, že jo…

Na kterém FS existuje fsck? Na základě představy o fsck, kterou výše naznačuješ (že zázrakem, záhadně, z křišťálové koule obnoví (meta)data ztracená kvůli selhávající RAM), nelze než konstatovat, že žádný FS nemá fsck; fsck dle tvých představ v tomhle vesmíru neexistuje.

Otázka je tedy stále stejná (už asi 10 let): S čím srovnáváš? Co je ten etalon, ten hypotetický ideální FS? Jmenuj ho, prosím. Jsem zvědavý. Už ho tajíš příliš dlouho. Nenechávej si to tajemství pro sebe.

Když se ti vlivem chyby RAM poškodí struktura, co budeš dělat?

Co si vojín Kefalín představuje pod takovým pojmem struktura? Asi metadata?

To↑ je ovšem nahrávka na smeč pro Btrfs, který (na rozdíl od špatných, zastaralých FS) implicitně (pokud uživatel nestanoví jinak) ukládá dvě kopie metadat (i na jednom zařízení), samozřejmě chráněné checksumy, aby se nepoškozená kopie (existuje-li ještě) dala s rozumnou pravděpodobností identifikovat. (Co když se obě kopie zapsaly ze stejné, poškozené RAM? Tak smůla, ale opět: S čím srovnáváme? Co by dopadlo lépe?)

Co tedy bude uživatel dělat?

• Pokud má béčkový zastaralý FS, například Ext4 nebo XFS, bude plakat, protože zastaralý FS nemá žádnou redundanci, aby mohl cokoliv obnovit, a fsck, jak už jsem psal, nemá křišťálovou kouli, aby si nenávratně ztracená (meta)data domyslel.
  Ba co hůř: v případě dat neumí vůbec poznat, že jsou poškozená!
• Pokud má rozumný souborový systém na jednom zařízení, první možnost záchrany jsou (implicitně) duplikovaná metadata chráněná obvyklými checksumy (v rámci téhož zařízení). Dokud rozsah poškození nezasáhne obě / všechny repliky důležitých metadat, s rozumnou pravděpodobností bude souborový systém čitelný a metadata opravitelná. Poškozená data, existují-li, budou identifikovatelná, ač (pochopitelně) neopravitelná. (Leda že by uživatel zvolil také duplicitní ukládání dat — který starý béčkový FS takovou volbu má, mimochodem?)
• Pokud má rozumný souborový systém na několika zařízeních, přibývá mnoho dalších možností opravy poškozených (meta)dat díky redundanci (kromě RAID 0). Checksumy řeknou, která replika nebo které RAID 5/6 bloky jsou (pravděpodobně) nepoškozené. Zbytek dat se doplní a dopočítá.
• Pokud je poškození takové, že jde všechno do kytek, půjde to na zastaralém FS do kytek s mnohem větší pravděpodobností. V takovém případě nezbude než sáhnout po oddělených zálohách (jiný systém, jiná instance FS). A právě atomické inkrementální zálohy nad řadou snapshotů jsou zase jedna z disciplín, ve kterých Btrfs září, zatímco zastaralé FS neumí nic.

Musím zopakovat (cca podvacáté) znova důvod, proč ZFS a Btrfs nemají zbytečný nesmysl zvaný fsck: Rozumný FS s checksumy, copy-on-write a redundancí musí být (v mezích zvolené redundance) funkční a odolný proti chybám, i když jsou chyby odhalené (nebo přímo nastanou) během provozu.

Izolovaný fsck, který funguje pouze na odmountovaném FS, nemá prakticky žádnou hodnotu, protože všechny podstatné mechanismy pro redundanci a obnovu / opravu dat musí být tak či onak součástí základního driveru příslušného FS. Neexistuje proto rozumný důvod tuhle logiku duplikovat, dvakrát odděleně testovat, (marně) doufat v udržení kompatibility mezi fsck s driverem, atd.