Btrfs

Btrfs (B-tree file system, vyslovováno "Butter F S" či "B-tree F S"^[2]) je copy-on-write souborový systém pro Linux vyvíjený od roku 2007 společností Oracle. Je šířen pod licencí GNU GPL.

Má na poli linuxových souborových systémů přinést některé vlastnosti ZFS od Sunu (nyní Oraclu), který nelze začlenit do zdrojových kódů linuxového jádra, neboť je uvolněn pod licencí CDDL (Common Development and Distribution License) nekompatibilní s GPL (licence jádra).

V linuxovém jádře je zařazen od verze 2.6.29-rc1.^[3] V roce 2014 byl uvolněn v produkční kvalitě.

Historie

Datová struktura, na které je Btrfs založen – copy on write B-strom – byla původně navrhnuta Ohadem Rodehem, výzkumníkem z IBM, na prezentaci USENIX v roce 2007.[1] Chris Mason, inženýr pracující na ReiserFS pro SUSEse později toho roku přidal do společnosti Oracle a začal pracovat na novém souborovém systému založeném na B-stromech.^[4]

Theodore Ts’o, jeden z předních vývojářů ext3 a ext4 souborových systémů, v roce 2008 prohlásil, že i přesto, že má ext4 pokročilé funkcionality, nejedná se o zásadní pokrok. Stále používá starou technologii, která se již významně neposune. Ts’o prohlásil, že Btrfs se pohybuje lepším směrem, protože „nabízí vylepšení ve škálovatelnosti, spolehlivosti a jednoduchosti spravování“.[2].

Btrfs 1.0, s hotovým diskovým formátem bylo původně naplánované na konec roku 2008,[3] a bylo přijato do jádra Linuxu v roce 2009.[4] Několik Linuxových distribucí[5] začalo nabízet Btrfs jako experimentální volbu při instalaci.[6][7][8]

V červnu 2011 byly do verze 3.0 Linuxového jádra přidány nové funkcionality Btrfs. Mezi nimi automatická defragmentace a nová metoda automatické opravy dat.[9]

V roce 2012, dvě Linuxové distribuce prohlásili Btrfs jako stabilní a změnili jeho stav z experimentálního na produkční. Oracle Linux v březnu,[10] následován SUSE Linux Enterprise v srpnu.[11]

V roce 2015 bylo Btrfs nastaveno jako výchozí souborový systém v operačním systému SUSE Linux Enterprise Server 12.[12]

V roce 2020 se Btrfs stalo výchozím souborovým systém ve Fedoře 33.^[5]

Funkcionality

Klonování

Btrfs nabízí klonovací operace, které automaticky vytvoří copy-on-write záznam souboru. Takto naklonované soubory nezabírají žádné dodatečně místo na disku, dokud jejich obsah není modifikován. Při modifikaci jsou zkopírovány (copy-on-write) a změna je uložena do kopie a původní soubor zachován nedotčen.

Na pozadí Btrfs nevytváří odkazy ukazující na již existující inody. Místo toho, Btrfs vytváří nové inody, které z počátku sídlí na stejném místě na disku jako originální soubor. Díky tomuto faktu, klonování funguje pouze v rozmezí jednoho Btrfs souborového systému. Od Linuxové verze 3.6 je možné toto omezení obejít za jistých okolností.^[6][7]

Klonování by nemělo být zaměňováno s pevnými odkazy, což jsou adresářové záznamy asociují více názvů s reálnými soubory na disku. Zatímco pevné odkazy jsou více méně různé názvy pro stejné soubory, klonování v Btrfs nabízí nezávislé soubory, které pouze zpočátku sdílí stejné místo na disku.^[8]

Dílčí svazky a snímky

Dílčí svazky mohou být vytvořeny kdekoliv v hierarchii souborového systému a mohou být i zanořené. Zanořené dílčí svazky se tváří jako podadresáře uvnitř jejich rodičovských dílčích svazků. Nápodobně kořenový dílčí svazek prezentuje svoje dílčí svazky jako podadresáře. Odstranění dílčích svazků není možné, dokud všechny dílčí svazky níže v hierarchii nejsou odstraněny. Jako následek, kořenový dílčí svazek nemůže být nikdy smazán.^[9]

Každý Btrfs souborový systém má vždy výchozí dílčí adresář, který je nastaven jako kořenový.^[9]

Btrfs snímek je dílčí svazek, který sdílí data (a metadata) s jiným dílčím svazkem. Je zde využit copy-on-write mechanismus, a tak modifikace snímku se neprojeví v původním dílčím svazku. Jakmile je vytvořen zapisovatelný snímek, je možné se k němu stavit jako alternativní verzi originálního souborového systému.

Copy-on-write mechanismus Btrfs garantuje, že vytváření snímků je velmi rychlé a z počátku zabírá zanedbatelné místo na disku. Jelikož snímek je dílčí svazek, vytváření zanořených snímků je také možné. Vytváření snímků není rekurzivní proces.

Vytvoření snímku adresáře není možné, protože mohou být pořízeny snímky pouze dílčích svazků. Tato limitace se ale dá obejít.^[6]

Dílčí svazek Btrfs se značně liší od tradičních logických svazků LVM. Zatímco s LVM, logický svazek je oddělené blokové zařízení, u Btrfs nemůže být s dílčími svazky takto nakládáno.^[10]

Send-receive

Pokud máme dva dílčí svazky (nebo snímky), můžeme spočítat jejich rozdíl (za použití btrfs send příkazu), který může být později aplikován (pomocí btrfs receive příkazu), potenciálně i na úplně jiném Btrfs souborovém systému. Send-receive operace obecně vytváří (a aplikuje) sadu operací, které je nutné provést k tomu abychom konvertovali jeden dílčí svazek do druhého.^[11]

Toto může být využito například jako jednoduchý mechanizmus inkrementálního zálohování nebo způsob replikace souborového systému.^[12]

Kontrola o zotavení

Unixové systémy tradičně používají program fsck na kontrolu a opravu souborových systémů. Pro Btrfs je tato funkcionalita implementována příkazem btrfs check. Od verze 4.0 je tato funkcionalita považována za stabilní. Od srpna 2017 ovšem oficiální dokumentace Btrfs doporučuje její použití teprve až po vyzkoušení ostatních metod.^[13]

Existuje i další nástroj, btrfs-restore, který může být použit pro získání souborů z poškozeného souborového systému, který se nedaří zavést. Tento nástroj souborový systém nemodifikuje a je tudíž nedestruktivní.^[14]

Během normálního používání je Btrfs většinou samo opravující se a je schopno se zotavit z chyb díky pravidelnému ukládání dat na pevná úložiště. Ve výchozím nastavení toto Btrfs provádí každých 30 sekund, ale je možné tento interval změnit. V nejhorším případě by tak mělo dojít maximálně ke ztrátě dat vytvořených v posledních třiceti sekundách.^[15]

Návrh

Původní návrh Ohada Rodeha na USENIXu v roce 2007 obsahoval poznámku, že B+ stromy, které jsou často používány jako struktury dat na pevných úložištích u databází, by nemohli efektivně umožňovat copy-on-write mechanismus založený na snímkách, protože jejich listy jsou propojeny. Kdyby jeden list byl zkopírován při zápisu, jeho rodiče a sourozenci by také museli být zkopírovány stejně tak jako jejich rodiče a sourozenci a tak dále dokud by nebyla zkopírována celá struktura. Místo toho navrhl upravený B-strom (který neobsahuje provázané listy) s počtem referencí asociovaným s každým vrcholem, ale uloženým v jiné datové struktuře. Mezi další změny patřila i úprava balancovacího algoritmu stromu, aby se více kamarádil s copy-on-write mechanismem. Výsledkem je struktura s vysokým výkonem, která je schopná provádět copy-on-write a zachovat konkurenci.^[16]

Btrfs je strukturováno do vrstev několika takovýchto stromů. Stromy ukládají generické prvky uložené jako 136bitové klíče. Nejvyšších 64 bitů reprezentuje unikátní identifikátor. Prostředních osm bitů je rezervováno pro typ. Posledních 64 bitů jsou využívány typ od typu. Tudíž prvky stejného objektu skončí ve struktuře vedle sebe.^[17]

Vnitřní prvky stromů jsou reprezentovány jako obyčejné seznamy párů klíč-ukazatel, kde ukazatel je logické blokové číslo potomka. Listy obsahují klíče uložené vpředu vrcholu a data na konci, kde se rozdíl mezi nimi postupně zmenšuje jak se vrchol zaplňuje daty.

Související články

• ZFS
• ext4
• ext3

Reference

V tomto článku byl použit překlad textu z článku Btrfs na anglické Wikipedii.

Externí odkazy

• Obrázky, zvuky či videa k tématu Btrfs na Wikimedia Commons
• Oficiální stránky projektu
• JLS2009: A Btrfs update (LWN.net)
• Krátká historie Btrfs (AbcLinuxu.cz)
• Btrfs: zajímavý, ale nekompletní souborový systém (Root.cz)
• Porovnání výkonu Btrfs bez/včetně Zlib a LZO komprese