Názor k článku Souborový systém Btrfs: kontrola dat a pokročilé použití od Křišťan Surname - Nebudu opakovat, co už napsali jiní (hlavně p....

Nebudu opakovat, co už napsali jiní (hlavně p. Crhonek), přidám svoje:

Zvolil jsem btrfs jako filesystem i distribuční metodu pro polo-průmyslovou síť "IoT" embedded zařízení. Na poli hardwarovém klasika - SoC s "áčkovým" ARM Cortexem, pár set mega DDR3 paměti, pár GB NAND flashe. Flash je klasicky pomocí mtdparts rozdělen na různé oddíly podle boot předpisu čipsetu, zbytek je formátován jako jeden btrfs oddíl. Klasická MBR/GPT tam není. V oddílu jsou subvolumes, které systém používá: read-only rootfs, jeden s konfigurací, jeden se persistentním stavem prvků, nějaké logy atd.

Updaty se distribuují jako btrfs delty, tj. na mastering mašině se provede btrfs send -p starý_subvol nový_subvol | zstd | nějaké crypto s podpisy > update.bin, to se dá na veřejný server, odkud si to postahují stroje v terénu. Aplikují to na sebe, čímž vznikne nový (tenký) subvolume nezávislý na stávajícím, přehodí se nějaký symlink, a systém se restartuje. Když dojde k chybě, nezávislý watchdog v bootloaderu symlink přehodí zpátky a nabootuje předchozí (known-good) subvol.

Super je, že díky architektuře těch delt není podmínkou, aby starý subvolume byl beze změn - deltu lze úspěšně aplikovat i na subvol, který byl např. zákazníkem modifikován. Jeho změny jsou tak propagovány i do nové verze.

Díky block-level součtům máme perfektní přehled o zdraví eMMC. Když někde selže modul, zpravidla to víme dřív, než se to projeví na provozu. Scrub odhalí všechno. V síti máme nasazeno lehce pod 5000 zařízení (kolem 24 tisíc device-years), k chybě způsobené btrfs nedošlo nikdy. Pár selhání flashe, pár PEBKACů.