Administrace komentářů

Myslím si, že vysvětlení by mohlo být tady v kapitole Direct IO and CRCs. Odkazovaný E-mail nabízí podrobnější vysvětlení. Ten log skutečně říká warning, nikoliv error. Třeba nějaká aplikace během toho balancování používala ošklivým způsobem direct IO (O_DIRECT). Jenom mi není jasné, proč celý balance kvůli tomu ohlásil chybu.

Kdy na tom oddíle naposledy proběhl scrub? Bohužel tohle v odkazovaném návodě úplně chybí. Před každou takovou větší operací, která mění strukturu filesystému, je rozumné nechat proběhnout scrub, čistě pro jistotu. To bych i teď doporučoval jako úplně první věc.

(Následující je jen kontext, který pravděpodobně nesouvisí s tímto konkrétním případem: Kdyby tam byl místo warning error, jmenovalo by se to silent data corruption. Btrfs chrání proti silent data corruption jednoduše tím, že nikdy nevrátí poškozená data. Má checksumy dat i metadat a jakmile checksum nesedí, příslušný blok se nedá přečíst. To je sice na první pohled kruté, ale hned na druhý pohled je to mnohem lepší, než kdyby se poškozená data dál šířila a kopírovala (jako u většiny jiných souborových systémů). U jednodiskového filesystému s jednou replikou dat to znamená, že příslušný blok je ztracený. U dvou replik dat na jednom disku nebo u RAID1/5/6 konfigurace přes více disků se naštěstí blok obvykle dá opravit; buď se načte z druhé repliky, nebo se dopočte z parity — samozřejmě jen pokud checksum u druhé repliky či checksumy u dostatku "paritních" bloků sedí.)

Zpět k tématu: Tady je popsaný příkaz, který umožňuje identifikovat soubor (nebo adresář), který se četl, když ten kontrolní součet neseděl (podle čísla inodu):

sudo btrfs inspect-internal inode-resolve 264 /

Na jednom z mých strojů je pod tímto inodem vedený adresář /dev, na jiném je tam adresář /var. Je to samozřejmě individuální podle toho, jak proběhla instalace toho systému; takhle nízká čísla inodů dostanou obvykle soubory a adresáře vytvořené na filesystému jako jedny z prvních.

Kdyby byl poškozený adresář /dev, jeho smazání a nahrazení (pomocí live média) je celkem triviální záležitost. Kdyby byl ovšem poškozený adresář /var, běhal by mi z toho mráz po zádech. Jak ovšem naznačuje fakt, že jde o warning, nikoliv error, nemusí tohle nic zásadního znamenat. Doporučuji prostě spustit scrub a pak se uvidí, co a jak.