Administrace komentářů

Jak může bez atomicky udržovaných checksumů dat poznat konzistentní stav?

Konzistentní stav se pozná tak, že jsou právě všechny obsazené bloky dosažitelné, všechny soubory mají čitelná metadata (jak bylo ukázáno), nejsou tam hardlinky na adresáře atd. Samozřejmě to není konzistentní stav z hlediska aplikací a toho že soubor co jsi někam uložil a poté úspěšně proběhl fsync tam taky najdeš. Ale většinou je dost jasně vidět kterých souborů se to týká (právě z těch metadat) a tedy co je potřeba obnovovat a jestli je to problém.

Jinak souhlasím, že taková věc by neměla projít scrubem bez varování (a bohužel prošla).

Protože scrub jenom zaručuje, že bloky, co jsme přečetli, jsou bloky, co jsme (někdy) před tím zapsali. V žádném případě nezaručuje, že obsah těch bloků je smysluplný, a bohužel ani příliš nezaručuje, že bloky jdou chronologicky. Bohužel se tohle málo ví, a leckdo říká "haha mám scrub, nepotřebuju fsck!", a je potřeba upozorňovat na to, že to tak není. A pak má na FS chyby, o kterých se nemá jak dozvědět, a narazí na ně až v okamžiku, kdy se třeba pokusí zapsat do nějakého souboru. (btrfs je dobrej že alespoň má nějaký fsck, ZSF pokud vím nemá vůbec nic)

Nechápu ovšem, oč lépe by stejnou situaci ustál Ext4 a jakou by mi dal záruku, že jde opravdu jen o poškození metadat v nějakém adresáři a že nejsou poničené moje datové bloky.

Nedal by ti takovou záruku (btrfs ti ji taky nedává, stejně jako se poškodily bloky s metadaty se mohly poškodit i bloky s daty), ale pro opravu bys nemusel použít nástroj, který má na začátku dokumentace tučné varování, že ho nemáš používat.

A tohle^^^ platí pro Ext4 mnohem víc než pro Btrfs, že jo.

Nevím proč by to mělo platit mnohem víc, napsal jsem nějaké důvody hovořící pro btrfs a nějaké pro ext4 a jejich přesné vyhodnocení by vyžadovalo v podstatě neproveditelnou analýzu konkrétního nasazení.