Administrace komentářů

Žurnálování obecně nijak neřeší silent data corruption. Ano, může odchytit některé specifické případy, ale obecně problém nijak neřeší, protože žurnály i „perzistentní“ můžou disky zapisovat v libovolném pořadí, klidně i nesprávném z hlediska odolnosti vůči výpadkům, a protože zápis chybných dat může nastat i z jiných důvodů než kvůli výpadku napájení. Co když disk ze své přeuspořádané fronty operací stihne do žurnálu či do stromu inodů zaznamenat úspěšný zápis několika bloků dat, ale bloky samotné už kvůli výpadku napájení nezapíše? Ani tento případ žurnálování samo o sobě neřeší. Zato checksumy ano. (Přesněji řečeno, naprosto zásadně snižují pravděpodobnost, že se na to nepřijde, když už se to stane.) Na filesystému s jednou replikou dat je pak příslušný soubor ztracený, ale s více replikami dat (ať na jednom disku nebo na více discích (RAID)) se data dají celkem deterministicky obnovit a zachránit. Jistě, pokud neselžou 2 související bloky v RAID5 nebo všechny související bloky v RAID1. Pak se situace převádí na případ s jednou replikou dat na jednom disku — ztracený soubor, ale s přesným oznámením, který to je.

S tou nedovařeností nějak nezmiňuješ, jestli třeba vyčištění space cache pomáhá nebo zda a jak jsi otestoval, že všechny disky v těch 6TB polích jsou opravdu v pořádku a že žádný z nich nemá divný problém s throughputem atd. atp. Jasně, mohl jsi narazit na nějaký nový výkonnostní bug v Btrfs, ale bez vyloučení dostatečného počtu dalších možných příčin se to dá těžko přesvědčivě prokázat.