Vlákno názorů k článku Souborový systém Btrfs: kontrola dat a pokročilé použití od anonym - Zajímavé srovnání by bylo, kolik % všech filesystémů...

Zajímavé srovnání by bylo, kolik % všech filesystémů na BTRFS, nakonec chcíplo.

Upřímně, mám kolem sebe několik desítek Linuxáků a snad každý, má s BTRFS tak mizerné zkušenosti, že si to netroufne nasadit ani na pracovní notebook, nedejbože někam klientovi do produkce.

BTRFS nemá oproti ZFS absolutně nic navíc, ba naopak, tunu funkcionality postrádá.
Proč používat BTRFS, když si ZFS modul může zbuildit kde kdo, na kde čem, co je 64bit?

Proč používat BTRFS, když si ZFS modul může zbuildit kde kdo, na kde čem, co je 64bit?

To je asi na dlouhou diskusi. Spousta by ocenila mít ZFS out-of-box, což je dnes docela problém. Pak samozřejmě můžete uvažovat i o provozu na FreeBSD, které má i některé další výhody oproti linuxu (a ty, kteří by ocenili ZFS by mohli i tyto výhody ocenit).

Přesto Btrfs je zajímavá alternativa k ZFS a snad se najdou uživatelé, kteří budou mít sílu pomoci odladit i ty více enterprise funkcionality.

BTRFS nemá oproti ZFS absolutně nic navíc, ba naopak, tunu funkcionality postrádá.

To záleží na kritériích. BTRFS používám kontinuálně od roku 2011 a za jednu z hlavních vlastností považuju flexibilitu a to na mnoha úrovních. Multidevice podle mých představ. Kdykoliv přidám, kdykoliv odeberu disk. Nejstarší FS, který už udržuju jen tak pro srandu, má devid přes 30. Tohle s ZFS neuděláte. Ano, už jde sice odstranit vdev (čistě formálně) ale existující vdev nepředěláte (snad krom single na mirror a zpět). ZFS tuhle flexibilitu prostě postrádá, základní jednotkou je vdev a pool se staví z vdevů.

Další flexibilita BTRFS je v tom, že snapshot je subvolume a především nezávislý. Takže udělám snapshot nějaké subvolume a tu původní smažu. Takto můžu udělat celý strom subvolume a libovolné z nich promazat.

U ZFS je snapshot datasetu pevně svázán s tím datasetem. Nemůžu smazat dataset a nechat si jen jeho snapshoty. Ano, můžu udělat clone nějakého snapshotu a získám nový dataset, ale ten je ale navázán na původní snapshot (a ten zase na původní dataset). Ano, můžu tento snapshot pomocí zfs promote posunout na nový dataset a ten starý dataset smazat, ale zase nemůžu smazat ten snapshot, ze kterého jsem udělal clone. Prostě už tam bude navždy.

Tohle strašně komplikuje použití těch datasetů.

Na BTRFS mám postavené kontejnery (nspawn). Některé slouží jako template, a ty občas updatuju. Kdykoliv z těchto template udělám nový kontejner. Staré template subolume mohu kdykoliv promazat.

Tohle na ZFS prakticky neuděláte. Když z jednoho snapshotu naklonujete více datasetů (třeba pro jaily) , tak se těch původních snapshotů nezbavíte. Takže nové jaily nakonec řeším plnou kopií template přes zfs send / receive.

Díky za praktické srovnání ZFS a BTRFS.

Od verze 0.8 jde skládat zpooly z kolika vdevů chceš a dělat s tím psí kusy dle libosti. Dokonce lze celej zpool přenést na menší vdev, to dřívější verze neuměly, pravda.

Ano, snapshoty se chovají rozdílně, s tím je nutné počítat.

Mně na BTRFS například chybí:
Šifrování, l2arc cache a zil cache. :-)

Osobně používám Btrfs přes dva roky v noťasu (Ubunut 18.04.3 LTS | kernel 5.3.18 | btrfs-progs v4.15.1) - dva 512GB SSD disky na RAID0 - jeden mSATA a druhý SATA3. Vytáhnu z toho, tak rychlost čtení a zápisu až na cca 900MB/s a 2x větší IOPS. Vytvořené subvolume na / alias @ a /home alias @home, k tomu jeden klasický disk místo dvd mechaniky, který používám pro nedůležitá data a jako zálohovací. Mám napsaný bash skript spouštěný cronem každou hodinu a vytvářející jednou denně snapshot z @ a @home a tyto snapshoty mi posílá skriptík rovnou přes btrfs send | btrfs receive na klasický disk s Btrfs samozřejmě, kde jsou inkrementálně zálohované, mám to zautomatizované tak, že se o to vůbec nestarám. Na RAID0 mi to promazává více jak 14 dní staré snapshoty automaticky (pořád mám ale snapshoty přistupnné 3 měsíce zpět na jiném fyzickém disku, 3 měsíce je až až pro mé potřeby), jednou za měsíc se odleje inkrementálně poslední snapshot @home a @ na externí USB disk, pro jistotu.

Obnova v případě vážné havárie disků v RAID0 je úplně jednoduchá bootnu live distro na usb a použiji čtyři příkazy v terminálu:

mkfs.btrfs -m raid1 -d raid0 /dev/sda1 /dev/sdb1 - vytvořím si nový souborový systém s metadaty v raid1 a daty v raid0
btrfstune -U XXXXXX /dev/sda1 - změním UUID prvního disku na původní, protože po naformátování je mu přiděleno jiné náhodného UUID, tak abych jej nemusel měnit v fstab a grubu
btrfs send /media/HDD/.snap­shots/20200218_0­90101/@home | btrfs receive /media/XXX/@home - pošlu si vybraný snapshot s adresářem home na nově vytvořený Btrfs filesystém
btrfs send /media/HDD/.snap­shots/20200218_0­90101/@ | btrfs receive /media/XXX/@ - pošlu si vybraný snapshot s adresářem / na nově vytvořený Btrfs filesystém

Změním zapsané snapshoty, které jsou ještě v read only režimu (byly to snapshoty v inkrementálním režimu) na zapisovatelné
btrfs property set media/XXX/@home ro false
btrfs property set media/XXX/@ ro false

Rebootnu noťas a jedu :)

Btrfs je podle mého skromného názoru báječný souborový systém i pro desktop použití, docela jsem s ním dříve hodně cvičil, když jsem se jej snažil pochopit a zkoumal jej, ale nikdy mi nezhavaroval tak, že bych se nemohl dostat k datům.

Nejvíc na něm oceňuji lehkost práce se snapshoty, implementaci interní komprese zstd, a možnost přidávat a odebírat disky dle potřeby, ještě by to chtělo implementovat interní šifrování a nemělo by to chybu.

18. 2. 2020, 15:20 editováno autorem komentáře

"Obnova v případě vážné havárie disků v RAID0 je úplně jednoduchá" - jako komické číslo je takové konstatování fakt úžasné, to je jak nabízet nemožné ihned a zázraky do 5 minut :D

U ZFS za mna napr chyba moznost zmensit ulozisko a ma to vacsie pamatove naroky.... Samozrejme nebavime sa o enterprise

Od verze 0.8 s tím není žádný problém, sám jsem migroval původně 750GB zpool na 120GB mirror z SSD.

U ZFS za mna napr chyba moznost zmensit ulozisko a ma to vacsie pamatove naroky.... Samozrejme nebavime sa o enterprise

To je právě životní nesnáz pro Btrfs. Funkce má naprojektované podle enterprise filesystémů, ale ve skutečnosti s ním zatím pracují převážně jedinci, kteří tyto funkce nevyžadují. Pro málé (nebo domácí) použití je Btrfs navržený hodně velkolepě, ale nedopracovaný. Pro enterprise použití není naplánován dost velkolepě (dnes je konkurence dál) a zároveň není dokončený a zároveň jsou zvoleny kompromisy pro "malé" použití.

Btrfs by potřeboval nějakou vzpruhu, někoho, kdo se enterprise funkcí ujme a opravdu je dotáhne a hlavně vymyslí, jak mohou oba scénáře použití dlouhodobě koexistovat.

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ů.

"Na poli hardwarovém klasika - SoC s "áčkovým" ARM Cortexem, pár set mega DDR3 paměti, pár GB NAND flashe."

Asi sem lehce zaspal dobu, ale vetsina IoT zarizeni, co pouzivam, ma RAM v radu desitek kB a Flash v radu jednotek MB :D.

Proto ty uvozovky, že :-)

Je to normální moderní PLC, ale marketing trvá na používání buzzwords jako IoT a cloud.