btrfs je evidentne obslehly zfs, tedy stejne jako tam je kazda zmena diky copy-on-write a.t.o.m.i.c.k.a! tedy se proste zmena zapise nebo nezapise (a zustava predchozi stav). a tedy zadny fsck neni a nebude potreba.
To je sice hezká teorie, ale v praxi může nastat spousta situací, které prostě můžou fs poškodit nezávisle na tom že změny v btrfs jsou atomické. Můžou to být chyby v kódu btrf samotného, chyby v nějakém jiném ovladači. Nebo se objeví problém s HW. Nebo to může způsobit výpadek elektřiny. Nebo...
Takže fsck potřeba prostě je.
Hmmm, pripomina mi to debatu nad ZFS par let zpet. I tehdy zaryti UFSaci necetli dokumentaci a chteli fsck... Vsechna data jsou ulozena s CRC32 checksumy, ktere jsou pri kazdem readu kontrolovany, abys nedostal corrupted data. Takze pokud moci mermo potrebujes vyuzit disk io a cpu, misto fsck pouzij find + cat se stejnym efektem.
btrfs se muze rozbit, povedlo se mi to nekolikrat (hlasil jsem to i do btrfs mailing listu), zejmena pokud nad btrfs pracuje dm-crypt nebo jsou vyple barriery... pak staci jeden vypadek proudu a je to
Pripomina mi to moji zkusenost s Reiser4. Skvely system, rychly, ma tailpacking a transparentni kompresi, ale jednou mi vypadek shodil server pri zapisu, par bloku odeslo do magnetickeho nebe a pulka OS byla v ****. Chce to nejenom fsck, ale musi byt i odladene.
