Administrace komentářů

Proč si myslíš, že Btrfs nedokáže opravit silent data corruption? Rozhodně to umí v případě metadat, protože metadata mají implicitně „RAID“ režim DUP, tj. všechna Btrfs metadata jsou zapsaná dvakrát, má-li filesystém jen jeden disk. (Má-li víc disků, jsou obvykle jednou na každém disku, nenastaví-li to uživatel jinak.) V případě běžných dat je i samotná detekce velmi prospěšná, ale uživateli samozřejmě nic nebrání zapisovat i data v režimu DUP, chce-li (samozřejmě s náležitou režií). Dvě kopie metadat jsou každopádně velmi podstatnou výhodou Btrfs, na kterou se velmi často zapomíná. Tady by se jeden ostatních filesystémů zeptal: Kdo z vás to má?!

V případě RAID1 je oprava silent data corruption samozřejmostí — to asi není třeba nijak podrobněji popisovat.

(Oprava drobných poškození na jednom disku s jednou jedinou kopií dat by taky byla technicky možná — stačilo by jen zvolit algoritmus pro checksumy, který něco takového umožňuje, a počítat s trochu větší řežií. Pokud ale vím, momentálně tohle implementováno není.)

Kolikrát jsem já osobně viděl silent data corruption, to vůbec není podstatné. Neprovozuju totiž miliony disků — narozdíl od takového Facebooku, který Btrfs zkušebně používá a jistě velmi dobře ví proč. Na Ext4 jsem silent data corruption viděl několikrát a následky rozhodně nebyly silent. Nešlo o skryté hardwarové selhání, ale spíš o kombinaci bugů, výpadků napájení a obvyklého lhaní disků ohledně perzistentního zápisu dat. Užil jsem si pak všech klasických projevů takové situace — souborů o velikosti 100 PB, nesmazatelných adresářů plných smetí, nesourodých kusů dat v některých konfiguračních souborech (a trvalo mi fakt dlouho, než jsem zjistil, proč nemůžu spustit třeba KDM) a tak dále a tak podobně. Na Btrfs jsem zatím ještě nic podobného nezažil. Při přerušení zápisu v nevhodnou chvíli budou špatně buď data, nebo checksum. V obou případech se aspoň odhalí, byť s nějakými false positives, že je něco špatně.