Administrace komentářů

Ne, není to nekonzistentní (a řeč byla opravdu o EXT4).

Právě ta absence několika kontrolních mechanismů, které má BTRFS navíc, je důvod, proč EXT4 vydrží víc. U EXT4 se prostě počítá s tím, že tam můžou být chyby a má nástroje na opravu. Když se kousek poškodí, tak zbytek filesystému zůstane funkční a fsck to při troše štěstí opraví (ve smyslu, že uvede filesystém do konzistentního stavu, nikoliv že zachrání data). A když se oprava nedaří, tak to jde připojit read-only.

U BTRFS je situace jiná. Tam se nepočítá s výskytem chyb. Předpokládá se, že je vše v pořádku a kontroluje se, že to tak opravdu je. Jenže pak něco v pořádku není a pokud není k dispozici kopie (např. díky duplikaci na druhý disk), tak filesystém jen suše oznámí, že je rozbitý a máš smůlu. Jednou ti umožní read-only mount a pak ani to ne. Nástroje na opravu prakticky žádné, ty co existují to spíš ještě dorazí. Jediná šance je vykopírovat data na jiný disk a vyrobit filesystém znovu. Pokud je to například zálohovací disk s hromadou snapshotů, tak je o zábavu postaráno (vlastní zkušenost).

Jasně, poškození dat na disku je chyba disku, nikoliv filesystému, ale filesystém je to, co se s tím musí umět vyrovnat. Například to, že poškozený disk lze v read-only režimu připojit jen jednou je jednoznačně blbost vývojářů – když to jde přečíst jednou, musí to jít i podruhé. Je to právě přístup k zotavení po chybách co dělá BTRFS tak špatnou pověst (a oprávněně).