Portál AbcLinuxu, 8. května 2024 21:33
V rámci Jaderných novin na LWN.net byl zahájen nový seriál článků na téma systému souborů Btrfs. Na AbcLinuxu už dříve vyšly dva kvalitní články o Btrfs, přesto věříme, že vás tento seriál zaujme.
Tento systém souborů si za dobu své krátké existence prošel snad každou částí cyklu mediálního humbuku. Nějakou dobu to byl systém souborů příští generace, který měl vyřešit mnoho našich problémů; distribuce válčily, aby se ukázalo, kdo jej bude mít jako výchozí jako první. Pak se ukázalo, že všichni ti zkušení vývojáři systémů souborů si nedělali legraci, když tvrdili, že trvá celé roky, než je systém souborů dostatečně důvěryhodný na to, aby mu bylo možné svěřit důležitá data. Aktuálně je možné jít na konferenci a slyšet na Btrfs akorát samé stížnosti; vypadá to, že došlo na vystřízlivění. A než bude Btrfs opravdu připravené, tak si asi řada lidí bude myslet, že je už úplně zastaralé.
Pravda ale nemusí být tak deprimující. Vývoj Btrfs pokračuje se silným důrazem na stabilitu a výkon. Problémy jsou opravovány a uživatelé se po tomto slibném systému souborů znovu poohlížejí. Hraje si s ním více uživatelů a openSUSE v září dokonce zvažovalo, že by mohl být jako výchozí systém souborů. Situace se možná stabilizuje a možná se pomalu dostáváme do nové fáze, kde se – stále pomalu – usadí jako jeden z klíčových systémů souborů na Linuxu.
Tento článek je zamýšlen jako první díl seriálu pro uživatele, kteří by rádi zkoušeli a hráli si se systémem souborů Btrfs. Začneme se základy návrhu Btrfs a jak je vyvíjen; pak se podrobně podíváme na specifické funkce Btrfs. V tomto seriálu se ale určitě neobjeví výsledky benchmarků; ukazuje se, že řádné testování systémů souborů je obtížné; je také silně závislé na zátěži a hardwaru. Nekvalitní výsledky by nikomu nepomohly, proto to ani nebude zkoušeno.
Není to tak dlouho, co uživatelé Linuxu stále pracovali se systémy souborů, které se od dob Unixu moc nevyvinuly. Systém souborů ext3 například stále používá blokové ukazatele: inode každého souboru (centrální datová struktura s veškerými informacemi o souboru) obsahuje seznam ukazatelů na každý jednotlivý blok obsahující data souboru. Tento návrh fungoval dobře, pokud byly soubory malé, ale špatně škáluje: 1GB soubor by vyžadoval 256 tisíc ukazatelů na blok. Novější systémy souborů (včetně ext4) místo toho používají ukazatele na „extents“; každý extent je skupinou souvislých bloků. Jelikož se systémy souborů snaží ukládat data souvisle, ukládání na bázi extentů značně snižuje režii spojenou se správou prostoru souboru.
Btrfs samozřejmě používá extenty také. Ale značně se liší od většiny jiných systémů souborů: jde o systém souborů typu copy-on-write („COW“, kopíruj při zápisu). Kdykoliv jsou na ext4 přepisována data, nová data jsou zapsána přes stávající data na úložném zařízení, čímž je původní kopie zničena. Btrfs místo toho přesune přepisované bloky jinam v rámci systému souborů a zapíše nová data tam, takže starší kopie zůstane nedotčena.
Režim COW přináší řadu výhod. Jelikož nejsou stará data přepisována, obnova po pádech a výpadcích dodávek energie je přímočařejší; pokud nebyla transakce dokončena, pak zůstává původní stav dat (a metadat) na původním místě. Proto mimo jiné nemusí systém souborů typu COW implementovat oddělený žurnál pro získání odolnosti proti pádům.
Copy-on-write navíc nabízí zajímavé nové funkce, především pak snapshoty. Snapshot je virtuální kopie obsahu systému souborů; je možné jej vytvořit bez jakéhokoliv kopírování dat. Pokud je později změněn blok dat (buď ve snapshotu nebo v originálu), pak je tento jediný blok okopírován, zatímco původní data se nadále sdílejí. Snapshoty se mohou používat jako takový „stroj času“ nebo pro jednoduchou obnovu systému při selhání aktualizace.
Další důležitou funkcí Btrfs je vestavěný správce jednotek. Systém souborů Btrfs může pokrývat několik fyzických zařízení při různých konfiguracích RAID. Jakákoliv jednotka (sada jednoho nebo více fyzických zařízení) může navíc být rozdělena na „podjednotky“, které můžeme vnímat jako nezávislé systémy souborů sdílející společnou sadu fyzických jednotek. Btrfs tedy umožňuje spojit některá nebo všechna úložná zařízení v systému do jednoho velkého zdroje, který pak může být sdílen mezi různými systémy souborů a každý bude mít svá vlastní omezení využití.
Btrfs nabízí celou škálu dalších funkcí, které nejsou jinými linuxovými systémy souborů podporovány. Může provádět úplné kontrolní součty dat i metadat, což jej činí robustním při poškození dat hardwarem. Úplné kontrolní součty jsou ale náročné, takže se dá očekávat, že nebudou používány na mnoha místech. Data mohou být ukládána na disku v komprimované podobě. Funkce přijmi/odešli se dá mimo jiné používat jako součást mechanismu pro přírůstkové zálohování. Funkce pro online defragmentaci může za běhu systému opravit fragmentované soubory. V jádře 3.12 jsme mohli zaznamenat přidání funkce pro offline deduplikaci; hledá bloky obsahující stejná data a sdružuje je do jediné sdílené kopie. A tak dále.
Je nutné upozornit, že přístup copy-on-write není zadarmo. Je evidentně nutné provádět nějaké garbage collection (úklid nepoužívaných dat), jinak by kopie bloků rychle spotřebovaly všechno volné místo na systému souborů. Kopírování bloků může navíc zabírat více času než prosté přepsání a současně značně zvýšit spotřebu systémové paměti. Operace COW mají také tendenci fragmentovat soubory, čímž ničí kontinuální rozvržení souborů, na kterém kód systému souborů tak tvrdě pracoval. Fragmentace vadí na SSD méně než na mechanických discích, ale i v případě SSD nebude přístup k fragmentovaným souborům tak rychlý.
Takže všechna ta skvělá funkčnost obsažená v Btrfs nebude zadarmo. V mnoha situacích se administrátoři mohou rozhodnout, že režie spojená s Btrfs nevyvažuje výhody; na takových místech poslouží systémy souborů jako ext4 nebo XFS. Pro ostatní ale bude flexibilita a funkčnost nabízená Btrfs jistě dosti přitažlivá. Jakmile bude obecně přijato, že je Btrfs použitelné pro ostré nasazení, tak se asi začne objevovat na řadě systémů.
Jedna z obav, které váš redaktor LWN slyšel na chodbách během konferencí, je, že se tempo vývoje Btrfs zpomalilo. Pro ty zvědavé z vás je tu přehled počtu sad změn v kódu Btrfs v jádře, a to po přibližně ročních intervalech:
| Rok | Počet sad změn | Počet vývojářů |
|---|---|---|
| 2008 (2.6.25—29) | 913 | 42 |
| 2009 (2.6.30—33) | 279 | 45 |
| 2010 (2.6.34—37) | 193 | 33 |
| 2011 (2.6.38—3.2) | 610 | 67 |
| 2012 (3.3—8) | 773 | 63 |
| 2013 (3.9—13) | 671 | 68 |
Tato čísla nevykazují zpomalování vývoje; během roku 2010 došlo ke zjevnému zpomalení, ale pak se stav ustálil. Při pohledu na tato čísla je ale pořeba mít pár věcí na paměti. První je, že počáteční práce představovala přidávání nových funkcí do zbrusu nového systému souborů, zatímco práce v roce 2013 zahrnuje téměř výhradně opravy. Takže velikost změn se značně zmenšila, ale dalo by se říct, že tak to má být.
Dalším důležitým bodem je to, že příspěvků od tvůrce Btrfs Chrise Masona za poslední roky jednoznačně ubylo. Částečně kvůli tomu, že pracoval na kódu btrfs-progs v uživatelském prostoru – což je práce, která není výše zohledněna – ale je také jasné, že byl vytížen dalšími pracovními záležitostmi. Bude zajímavé sledovat, jak se věci změní po přechodu Chrise a známého přispěvatele do Btrfs Josefa Bacika do Facebooku.
Abychom to shrnuli: objem nového kódu zařazovaného do Btrfs se za poslední roky jednoznačně zmenšil, ale to je dobrá zpráva pro všechny, co by brzy rádi viděli stabilní systém souborů. Na tomto systému souborů se intenzivně pracuje a je pravděpodobné, že jak se distribuce budou více poohlížet po Btrfs, tak se pozornost vývojářů ještě zvýší.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.