Btrfs - Btrfs

Btrfs
Vývojáři Facebook , Fujitsu , Fusion-IO , Intel , Linux Foundation , Netgear , Oracle Corporation , Red Hat , STRATO AG a openSUSE
Celé jméno Souborový systém B-stromu
Představeno Linux kernel 2.6.29, březen 2009 ; Před 12 lety ( 2009-03 )
Struktury
Obsah adresáře B-strom
Přidělení souboru Rozsahy
Limity
Max. velikost svazku 16  EiB
Max. velikost souboru 16 EiB
Max. počet souborů 2 64
Max. délka názvu souboru 255 znaků ASCII (méně pro vícebajtové kódování znaků , jako je Unicode )
Povolené znaky v názvech souborů Všichni kromě '/'a NUL( '\0')
Funkce
Zaznamenaná data Vytvoření (otime), modifikace (mtime), modifikace atributu (ctime) a přístup (atime)
Časové období 64bitový podepsaný int offset od 1970-01-01T00: 00: 00Z
Rozlišení data Nanosekunda
Atributy POSIX a rozšířené atributy
Oprávnění systému souborů POSIX a ACL
Průhledná komprese Ano ( zlib , LZO a (od 4.14) ZSTD )
Transparentní šifrování Plánováno
Deduplikace dat Ano
Kopírování na zápis Ano
jiný
Podporované operační systémy Linux , ReactOS
webová stránka btrfs .wiki .kernel .org Upravte to na Wikidata

Btrfs (vyslovuje se jako „lepší F S“, „máslo F S“, „b-strom F S“ nebo jednoduše tak, že se to vyjasní) je formát úložiště počítače, který kombinuje systém souborů založený na principu kopírování při zápisu (COW) s logickým správcem svazků (nezaměňovat s LVM Linuxu ), vyvinutý společně. Původně byl navržen v Oracle Corporation v roce 2007 pro použití v Linuxu a od listopadu 2013 byl formát souborového systému na disku v jádře Linuxu prohlášen za stabilní. Podle společnosti Oracle Btrfs „není skutečná zkratka“.

Btrfs je určen k řešení nedostatku sdružování , snímků , kontrolních součtů a integrace více zařízení v souborových systémech Linux . Chris Mason, hlavní autor Btrfs, uvedl, že jeho cílem bylo „nechat [Linux] škálovat úložiště, které bude k dispozici. Měřítko neznamená jen adresovat úložiště, ale také znamená umět jej spravovat a spravovat čistě rozhraní, které lidem umožňuje vidět, co se používá, a zvyšuje jeho spolehlivost “.

Dějiny

Snímek obrazovky s informacemi o použití souborového systému Btrfs

Základní datovou strukturu Btrfs‍-„ strom B na kopírování a zápis“ -původně navrhl výzkumník IBM Ohad Rodeh na prezentaci na USENIX 2007. Chris Mason, inženýr pracující v té době na ReiserFS pro SUSE , se ke společnosti Oracle připojil později toho roku a začal pracovat na novém systému souborů založeném na těchto B-stromech.

V roce 2008 hlavní vývojář souborových systémů ext3 a ext4 Theodore Ts'o uvedl, že přestože ext4 má vylepšené funkce, nejedná se o zásadní pokrok; používá starou technologii a je mezerou. Ts'o řekl, že Btrfs je lepší směr, protože „nabízí vylepšení škálovatelnosti, spolehlivosti a snadnosti správy“. Btrfs má také „řadu stejných designových nápadů, jaké měl reiser3 / 4 “.

Btrfs 1.0, s finalizovaným formátem na disku, byl původně naplánován na vydání z konce roku 2008 a nakonec byl přijat do hlavní řady jádra Linuxu v roce 2009. Několik linuxových distribucí začalo nabízet Btrfs jako experimentální volbu kořenového souborového systému během instalace.

V červenci 2011 byly funkce automatické defragmentace a čištění Btrfs sloučeny do verze 3.0 hlavní řady jádra Linuxu . Kromě Masona ve společnosti Oracle přispěla zlepšení výkonu také Miao Xie ve společnosti Fujitsu. V červnu 2012 Chris Mason odešel z Oracle do Fusion-io , který o rok později opustil s Josefem Bacikem, aby se připojil k Facebooku . Zatímco v obou společnostech Mason pokračoval ve své práci na Btrfs.

V roce 2012 dvě distribuce Linuxu přesunuly Btrfs z experimentálního do produkčního nebo podporovaného stavu: Oracle Linux v březnu, následovaný SUSE Linux Enterprise v srpnu.

V roce 2015 byl Btrfs přijat jako výchozí souborový systém pro SUSE Linux Enterprise Server 12.

V srpnu 2017 oznámil Red Hat v poznámkách k verzi pro Red Hat Enterprise Linux (RHEL) 7.4, že již neplánuje přesunout Btrfs, které byly od verze RHEL 6 beta zahrnuty jako „náhled technologie“, na plně podporovanou funkci, s poznámkou, že zůstane k dispozici v sérii vydání RHEL 7. Btrfs byl odstraněn z RHEL 8 v květnu 2019.

V roce 2020 byl Btrfs vybrán jako výchozí souborový systém pro Fedoru 33 pro desktopové varianty.

Funkce

Implementováno

Od verze 5.0 jádra Linuxu Btrfs implementuje následující funkce:

  • Většinou se v některých konfiguracích samoléčí kvůli povaze kopírování při zápisu
  • Online defragmentace a možnost připojení autodefragu
  • Online růst objemu a zmenšování
  • Online blokování přidávání a odebírání zařízení
  • Online vyvážení (pohyb objektů mezi blokovými zařízeními za účelem vyvážení zátěže)
  • Offline kontrola souborového systému
  • Online čištění dat za účelem hledání chyb a jejich automatické opravy u souborů s nadbytečnými kopiemi
  • RAID 0 , RAID 1 a RAID 10
  • Dílčí svazky (jeden nebo více samostatně připojitelných kořenů souborového systému v každém diskovém oddílu )
  • Transparentní komprese pomocí zlib , LZO a (od 4.14) ZSTD , konfigurovatelná podle souboru nebo svazku
  • Atomové zapisovatelné (prostřednictvím kopírování při zápisu) nebo pouze pro čtení Snímky dílčích svazků
  • Klonování souborů ( reflink , copy-on-write) přescp --reflink <source file> <destination file>
  • Kontrolní součty dat a metadat ( CRC-32C ). Nové hashovací funkce jsou implementovány od 5.5: xxHash , SHA256 , BLAKE2B .
  • Konverze na místě z ext3/4 na Btrfs (s vrácením). Tato funkce ustoupila kolem btrfs-progs verze 4.0, přepsaná od nuly v 4.6.
  • Union mount of read-only storage, known as file system seeding (read-only storage used as a copy-on-write backing for a writeable Btrfs)
  • Block discard (rekultivace místa na některých virtualizovaných nastaveních a zlepšení úrovně opotřebení na SSD s TRIM )
  • Odeslat/přijmout (ukládání rozdílů mezi snímky do binárního proudu)
  • Přírůstkové zálohování
  • Deduplikace dat mimo pásmo (vyžaduje nástroje uživatelského prostoru)
  • Schopnost zpracovávat odkládací soubory a odkládací oddíly

Implementováno, ale není doporučeno pro produkční použití

Plánováno, ale ještě nebylo implementováno

  • Deduplikace dat v pásmu
  • Kontrola online systému souborů
  • RAID s až šesti paritními zařízeními, překonávající spolehlivost RAID 5 a RAID 6
  • Objektová úroveň RAID 0, RAID 1 a RAID 10
  • Šifrování
  • Trvalá mezipaměť pro čtení a zápis ( L2ARC + ZIL , lvmcache atd.)

V roce 2009 se očekávalo, že Btrfs nabídne sadu funkcí srovnatelnou se ZFS , vyvinutou společností Sun Microsystems . Po akvizici společnosti Sun společností Oracle v roce 2009 se Mason a Oracle rozhodli pokračovat ve vývoji Btrfs.

Klonování

Btrfs poskytuje klonovací operaci, která atomicky vytvoří snímek souboru při kopírování . Takové klonované soubory jsou někdy označovány jako reflinky ve světle navrhovaného přidruženého systémového volání jádra Linuxu .

Klonováním souborový systém nevytvoří nový odkaz směřující na existující inode ; místo toho vytvoří nový inode, který původně sdílí stejné bloky disku s původním souborem. Výsledkem je, že klonování funguje pouze v rámci hranic stejného systému souborů Btrfs, ale od verze 3.6 jádra Linuxu může za určitých okolností překračovat hranice dílčích objemů. Skutečné datové bloky nejsou duplikovány; současně vzhledem k povaze Btrfs typu copy-on-write (CoW) nejsou úpravy žádného z klonovaných souborů v původním souboru viditelné a naopak.

Klonování by nemělo být zaměňováno s pevnými odkazy , což jsou položky adresářů, které spojují více názvů souborů se skutečnými soubory v systému souborů. Zatímco pevné odkazy lze pro stejný soubor považovat za různé názvy, klonování v Btrfs poskytuje nezávislé soubory, které zpočátku sdílejí všechny své bloky na disku.

Podpora pro tuto funkci Btrfs byla přidána ve verzi 7.5 jádra GNU , pomocí --reflinkmožnosti cppříkazu.

Kromě klonování dat ( FICLONE ) podporuje Btrfs také deduplikaci mimo pásmo prostřednictvím FIDEDUPERANGE . Tato funkce umožňuje sdílení souborů dvěma soubory s (byť částečně) identickými daty.

Subvolumes a momentky

Příklad snímků systému souborů Btrfs, spravovaných pomocí modulu snapper

Podobjem Btrfs lze považovat za samostatný prostor názvů souborů POSIX , který lze samostatně připojit předáním subvolnebo subvolidmožnostmi mount(8)obslužnému programu. Lze k němu také přistupovat připojením dílčího svazku nejvyšší úrovně, v takovém případě jsou dílčí svazky viditelné a přístupné jako jeho podadresáře.

Dílčí svazky lze vytvářet na libovolném místě v hierarchii systému souborů a lze je také vnořovat. Vnořené dílčí svazky se zobrazují jako podadresáře v jejich nadřazených dílčích svazcích, podobně jako způsob, jakým dílčí svazek nejvyšší úrovně prezentuje své dílčí svazky jako podadresáře. Odstranění dílčího svazku není možné, dokud nebudou odstraněny všechny dílčí svazky pod ním v hierarchii vnoření; v důsledku toho nelze odstranit dílčí svazky nejvyšší úrovně.

Jakýkoli souborový systém Btrfs má vždy výchozí subvolume, který je původně nastaven jako subvolume nejvyšší úrovně, a je připojen ve výchozím nastavení, pokud není předána žádná možnost výběru subvolume mount. Výchozí dílčí hlasitost lze podle potřeby změnit.

Btrfs Snímek je subvolume který sdílí svá data (a metadata) s nějakým jiným subvolume, pomocí funkce btrfs' copy-on-write a úpravy snímku nejsou viditelné v původním subvolume. Jakmile je vytvořen zapisovatelný snímek, lze s ním zacházet jako s alternativní verzí původního systému souborů. Chcete -li například přejít zpět na snímek, musí být upravený původní dílčí objem odpojen a snímek musí být namontován na své místo. V tom okamžiku může být také odstraněn původní dílčí svazek.

Povaha Btrfs typu copy-on-write (CoW) znamená, že snímky se vytvářejí rychle a zpočátku zabírají velmi málo místa na disku. Protože je snímek dílčím svazkem, je také možné vytvářet vnořené snímky. Pořizování snímků dílčího objemu není rekurzivní proces; pokud je tedy vytvořen snímek dílčího svazku, každý dílčí svazek nebo snímek, který již dílčí svazek obsahuje, je mapován do prázdného adresáře se stejným názvem uvnitř snímku.

Pořizování snímků adresáře není možné, protože snímky mohou mít pouze dílčí svazky. Existuje však řešení, které zahrnuje reflinky rozdělené mezi dílčí svazky: je vytvořen nový subvolume, který obsahuje reflinks cross-subvolume na obsah cíleného adresáře. Když je k dispozici, lze vytvořit snímek tohoto nového svazku.

Subvolume v Btrfs je zcela odlišný od tradičního logického svazku Logical Volume Manager (LVM). U LVM je logický svazek zařízení s odděleným blokem , zatímco dílčí svazek Btrfs není a nelze jej takto zpracovávat ani používat. Vytváření snímků dd nebo LVM btrfs vede k dataloss, pokud je připojen originál nebo kopie, zatímco jsou oba na stejném počítači.

Odeslat - přijmout

Vzhledem k jakékoli dvojici dílčích svazků (nebo snímků) mohou Btrfs mezi nimi generovat binární rozdíl (pomocí btrfs sendpříkazu), který lze později přehrát (pomocí btrfs receive), případně na jiném systému souborů Btrfs. Funkce odesílání a přijímání efektivně vytváří (a aplikuje) sadu úprav dat potřebných pro převod jednoho dílčího objemu na jiný.

Funkci odesílání/přijímání lze použít s pravidelně naplánovanými snímky k implementaci jednoduché formy replikace systému souborů nebo k provádění přírůstkových záloh .

Skupiny kvót

Příklad skupin kvót Btrfs

Skupina kvót (nebo qgroup ) ukládá horní limit prostoru, který může spotřebovat dílčí objem nebo snímek. Nový snímek zpočátku nespotřebovává žádné kvóty, protože jeho data jsou sdílena s jeho rodičem, ale poté mu budou účtovány poplatky za nové soubory a operace kopírování při zápisu u stávajících souborů. Když jsou kvóty aktivní, automaticky se vytvoří skupina kvót s každým novým dílčím objemem nebo snímkem. Tyto počáteční skupiny kvót jsou stavebními bloky, které lze seskupit (pomocí btrfs qgrouppříkazu) do hierarchií pro implementaci fondů kvót.

Skupiny kvót se vztahují pouze na dílčí svazky a snímky, přičemž kvóty vynucené na jednotlivých podadresářích, uživatelích nebo skupinách uživatelů nejsou možné. Řešení je však možné pomocí různých dílčích objemů pro všechny uživatele nebo skupiny uživatelů, které vyžadují vynucení kvóty.

Konverze na místě z ext2/3/4 a ReiserFS

V důsledku ukotvení velmi malého počtu metadat na pevných místech se Btrfs mohou deformovat tak, aby odpovídaly neobvyklým prostorovým rozvržením backendových úložných zařízení. Tento btrfs-convertnástroj využívá tuto schopnost k místní konverzi systému souborů ext2/3/4 nebo ReiserFS vnořením ekvivalentních metadat Btrfs do nepřiděleného prostoru-při zachování nezměněné kopie původního systému souborů.

Konverze zahrnuje vytvoření kopie celých metadat ext2/3/4, zatímco soubory Btrfs jednoduše ukazují na stejné bloky, jaké používají soubory ext2/3/4. To činí většinu bloků sdílených mezi těmito dvěma systémy souborů dříve, než se převod stane trvalým. Díky povaze kopírování při zápisu Btrfs jsou při všech úpravách souboru zachovány původní verze bloků dat souboru. Dokud se konverze nestane trvalou, budou k blokování nových úprav Btrfs používány pouze bloky, které byly v ext2/3/4 označeny jako volné, což znamená, že převod lze kdykoli vrátit zpět (i když tím se smažou všechny změny provedené po převodu na Btrfs).

Všechny převedené soubory jsou k dispozici a lze je zapisovat ve výchozím subvolume Btrfs. Řídký soubor, který obsahuje všechny odkazy na původní souborový systém ext2/3/4, je vytvořen v samostatném dílčím svazku, který lze samostatně připojit jako obraz disku pouze pro čtení, což umožňuje přístup k původnímu i převedenému systému souborů na stejný čas. Smazáním tohoto řídkého souboru se uvolní místo a převod bude trvalý.

Ve verzích 4.x hlavního jádra Linuxu byla místní konverze ext3/4 považována za nevyzkoušenou a používanou zřídka. Tato funkce však byla v roce 2016 přepsána od začátku na btrfs-progs4,6. a od té doby je považován za stabilní.

Konverze na místě z ReiserFS byla zavedena v září 2017 s jádrem 4.13.

Union montážní / osivová zařízení

Při vytváření nových Btrfs lze existující Btrfs použít jako souborový systém „seed“ jen pro čtení. Nový souborový systém pak bude fungovat jako překrývání při zápisu na seed, jako forma sjednocení . Semeno lze později odpojit od Btrfs, v tomto okamžiku rebalancer jednoduše zkopíruje všechna data semen, na která stále odkazuje nový souborový systém, před odpojením. Mason navrhl, že to může být užitečné pro instalační program Live CD , který se může spustit ze semene Btrfs jen pro čtení na optickém disku, znovu se vyrovnat s cílovým oddílem na instalačním disku na pozadí, zatímco uživatel pokračuje v práci, a poté vysunout disk k dokončení instalace bez restartu.

Šifrování

Chris Mason ve svém rozhovoru z roku 2009 uvedl, že podpora šifrování byla plánována pro Btrfs. Mezitím je řešením pro kombinování šifrování s Btrfs použití šifrovacího mechanismu celého disku, jako je dm-crypt  / LUKS, na podkladových zařízeních a vytvoření souborového systému Btrfs v horní části této vrstvy.

Od roku 2020 vývojáři pracovali na přidání klíčového hashu jako HMAC ( SHA256 ).

Kontrola a obnova

Unixové systémy tradičně při kontrole a opravě souborových systémů spoléhají na programy „ fsck “. Tato funkce je implementována prostřednictvím btrfs checkprogramu. Od verze 4.0 je tato funkce považována za relativně stabilní. V srpnu 2017 však dokumentace btrfs naznačuje, že bude použita až poté, co vyzkoušíte jiné metody obnovy.

Existuje další pojmenovaný nástroj, btrfs-restorekterý lze použít k obnově souborů z nepřenosného souborového systému, aniž by došlo k úpravě samotného poškozeného souborového systému (tj. Nedestruktivně).

Při běžném používání se Btrfs většinou samoléčí a dokáže se zotavit z poškozených kořenových stromů v době připojení, díky pravidelnému vyprazdňování dat do trvalého úložiště, standardně každých 30 sekund. Izolované chyby tedy způsobí, že při příštím připojení dojde ke ztrátě maximálně 30 sekund změn souborového systému. Tuto dobu lze změnit zadáním požadované hodnoty (v sekundách) pro commitmožnost připojení.

Design

Původní návrh Ohad Rodeha z USENIX 2007 poznamenal, že stromy B+ , které jsou široce používány jako datové struktury na disku pro databáze, nemohou efektivně povolit snímky založené na kopírování na zápis, protože jeho listové uzly byly spojeny dohromady: pokud byl list kopií -na napsáno, museli by být i jeho sourozenci a rodiče, stejně jako jejich sourozenci a rodiče a tak dále, dokud nebyl celý strom zkopírován. Místo toho navrhl upravený B-strom (který nemá žádnou listovou vazbu), s refcountem spojeným s každým uzlem stromu, ale uloženým v ad hoc volné mapové struktuře a určitými relaxacemi vyvažovacích algoritmů stromu, aby byly přátelské ke kopírování při zápisu . Výsledkem by byla datová struktura vhodná pro úložiště vysoce výkonných objektů, která by mohla provádět snímky kopie při zápisu při zachování dobré souběžnosti .

V Oracle o rok později Chris Mason začal pracovat na souborovém systému schopném pořizovat snímky, který by tuto datovou strukturu používal téměř výhradně-nejen pro metadata a data souborů, ale také rekurzivně pro sledování alokace prostoru samotných stromů. To umožnilo procházet všechny procházení a úpravy prostřednictvím jediné cesty kódu, proti které bylo třeba implementovat funkce jako kopírování při zápisu, kontrolní součet a zrcadlení pouze jednou, aby to prospělo celému systému souborů.

Btrfs je strukturován jako několik vrstev takových stromů, všechny využívající stejnou implementaci B-stromu. Stromy ukládají obecné položky seřazené podle 136bitového klíče. Nejvýznamnějších 64 bitů klíče je jedinečné ID objektu . Středních osm bitů je pole typu položky: jeho použití je pevně zapojeno do kódu jako filtr položky při vyhledávání stromů. Objekty mohou mít více položek více typů. Zbývajících (nejméně významných) 64 bitů je použito způsoby specifickými pro daný typ. Položky pro stejný objekt tedy skončí vedle sebe ve stromu, seskupené podle typu. Výběrem určitých hodnot klíčů mohou objekty dále zařazovat položky stejného typu v určitém pořadí.

Vnitřní stromové uzly jsou jednoduše ploché seznamy párů klíč-ukazatel, kde ukazatel je číslo logického bloku podřízeného uzlu. Listové uzly obsahují klíče položek zabalené do přední části uzlu a data položek zabalená do konce, přičemž dva rostou směrem k sobě, když se list plní.

Strom systému souborů

V každém adresáři se položky adresáře zobrazují jako položky adresáře , jejichž nejméně významné bity hodnot klíčů jsou hash jejich názvu souboru CRC32C . Jejich data jsou klíčem umístění nebo klíčem položky inodu, na kterou ukazuje. Položky adresáře dohromady tedy mohou fungovat jako index pro vyhledávání cesty k uzlu, ale nejsou používány k iteraci, protože jsou seřazeny podle jejich hash, což je efektivně náhodně permutuje . To znamená, že uživatelské aplikace, které by iterovaly a otevíraly soubory ve velkém adresáři, by tak generovaly mnohem více vyhledávání disků mezi nesousedícími soubory-pozoruhodný odliv výkonu v jiných souborových systémech s adresáři uspořádanými jako hash, jako je ReiserFS , ext3 (s povolenými indexy Htree ) a ext4, z nichž všechny mají názvy souborů s příponou TEA . Aby se tomu zabránilo, každá položka adresáře má položku indexu adresáře , jejíž klíčová hodnota položky je nastavena na čítač na adresář, který se zvyšuje s každým novým záznamem adresáře. Iterace nad těmito položkami rejstříku tedy vrací položky zhruba ve stejném pořadí, v jakém jsou uloženy na disku.

Soubory s pevnými odkazy ve více adresářích mají více referenčních položek, jednu pro každý nadřazený adresář. Soubory s více pevnými odkazy ve stejném adresáři zabalí všechny názvy souborů odkazů do stejné referenční položky. Jednalo se o konstrukční vadu, která omezila počet pevných odkazů na stejný adresář, nicméně mnoho se jich vešlo do jednoho stromového bloku. (Na výchozí velikosti bloku 4 KiB, průměrná délka názvu souboru 8 bajtů a záhlaví na název souboru 4 bajty by to bylo méně než 350.) Aplikace, které hojně využívaly více pevných odkazů stejného adresáře, jako je např. git , Gnus , GMame a BackupPC bylo pozorováno, že selhání v tomto limitu. Limit byl nakonec odstraněn (a v říjnu 2012 byl sloučen s čekajícím vydáním v systému Linux 3.7) zavedením rozšířených referenčních položek pro přelévání, které budou obsahovat názvy souborů s pevným odkazem, které se jinak nehodí.

Rozsahy

Data souborů jsou uchovávána mimo strom v rozsahu , což jsou souvislé běhy datových bloků disku. Výchozí bloky mají velikost 4 KiB, nemají záhlaví a obsahují pouze (případně komprimovaná) data souboru. V komprimovaných oblastech nejsou jednotlivé bloky komprimovány samostatně; proud komprese překlenuje celý rozsah.

Soubory mají datové položky rozsahu ke sledování rozsahů, které obsahují jejich obsah. Klíčová hodnota položky je počáteční bajtový posun rozsahu. To umožňuje efektivní vyhledávání ve velkých souborech s mnoha rozsahy, protože správný rozsah pro jakýkoli daný offset souboru lze vypočítat pouhým jedním vyhledáním stromu.

Snímky a klonované soubory sdílejí rozsahy. Když je malá část velkého takového rozsahu přepsána, může výsledné kopírování při zápisu vytvořit tři nové rozsahy: malý obsahující přepsaná data a dva velké s nemodifikovanými daty na obou stranách přepisu. Aby se předešlo nutnosti přepisovat nemodifikovaná data, může místo toho kopírování při zápisu vytvářet rozsahy knih nebo rozsahy, které jsou jednoduše řezy existujících rozsahů. Rozsáhlé datové položky to umožňují zahrnutím offsetu do rozsahu, který sledují: položky pro bookendy jsou ty s nenulovým offsetem.

Rozsáhlý alokační strom

Strom přidělení rozsah působí jako mapy přidělení pro souborový systém. Na rozdíl od jiných stromů nemají položky v tomto stromu ID objektů. Představují oblasti prostoru: jejich klíčové hodnoty drží počáteční posuny a délky oblastí, které představují.

Systém souborů rozděluje svůj přidělený prostor do blokových skupin, což jsou alokační oblasti s proměnnou velikostí, které se střídají mezi upřednostňováním rozsahů metadat (uzly stromů) a datových rozsahů (obsah souboru). Výchozí poměr skupin dat a metadat je 1: 2. Jsou určeny k použití konceptů alokátoru bloku Orlov k alokaci souvisejících souborů dohromady a brání fragmentaci ponecháním volného prostoru mezi skupinami. (Skupiny bloků Ext3 však mají pevná umístění vypočítaná z velikosti systému souborů, zatímco ty v Btrfs jsou dynamické a vytvářejí se podle potřeby.) Každá skupina bloků je spojena s položkou skupiny bloků . Položky uzlů ve stromu systému souborů obsahují odkaz na jejich aktuální skupinu bloků.

Položky rozsahu obsahují zpětný odkaz na uzel stromu nebo soubor zabírající tuto oblast. Pokud je rozsah sdílen mezi snímky, může existovat více zpětných odkazů. Pokud existuje příliš mnoho zpětných odkazů, aby se vešly do položky, vysypaly se do datových referenčních položek individuálního rozsahu . Uzly stromů zase mají zpětné odkazy na jejich obsahující stromy. Díky tomu je možné zjistit, které rozsahy nebo uzly stromů se nacházejí v jakékoli oblasti prostoru, a to tak, že vyhledáte rozsah B-stromů na dvojici offsetů, které tuto oblast zarovnají, a poté budete postupovat podle zpětných odkazů. Pro přemístění dat to umožňuje efektivní procházení z přemístěných bloků směrem nahoru, aby bylo možné rychle najít a opravit všechny odkazy na tyto bloky směrem dolů, aniž byste museli skenovat celý souborový systém. To zase umožňuje systému souborů efektivně zmenšit, migrovat a defragmentovat jeho úložiště online.

Strom alokace rozsahu, stejně jako u všech ostatních stromů v systému souborů, je kopírování při zápisu. Zápisy do systému souborů tak mohou způsobit kaskádu, při které změněné uzly stromu a data souboru budou mít za následek přidělení nových rozsahů, což způsobí změnu samotného stromu rozsahu. Aby se zabránilo vytváření zpětnovazební smyčky , mohou být uzly stromů rozsahů, které jsou stále v paměti, ale ještě nejsou potvrzeny na disku, aktualizovány na místě, aby odrážely nové rozsahy kopírování a zápisu.

Strom alokace rozsahu teoreticky činí konvenční bitmapu volného prostoru zbytečnou, protože strom alokace rozsahu působí jako B-stromová verze stromu BSP . V praxi se však ke zrychlení alokací používá červeno-černý strom bitmap velikosti stránky . Tyto bitmapy jsou uloženy na disk (počínaje Linuxem 2.6.37, přes space_cachemožnost mount) jako speciální rozsahy, které jsou osvobozeny od kontrolního součtu a kopírování při zápisu.

Kontrolní strom a drhnutí

CRC-32C kontrolní součty jsou počítány pro dat a metadat a uloženy jako kontrolní součet položek v kontrolním součtem stromu . Je zde prostor pro 256 bitů kontrolních součtů metadat a až do úplného uzlu (zhruba 4 kB nebo více) pro kontrolní součty dat. Btrfs má ustanovení pro přidání dalších algoritmů kontrolního součtu do budoucích verzí systému souborů.

Na souvislý běh přidělených bloků je jedna položka kontrolního součtu, přičemž kontrolní součty na blok jsou zabaleny od začátku do data položky. Pokud existuje více kontrolních součtů, než se vejde, vysypou se do jiného položky kontrolního součtu v novém listu. Pokud souborový systém při čtení bloku zjistí nesoulad kontrolního součtu, nejprve se pokusí získat (nebo vytvořit) dobrou kopii tohoto bloku z jiného zařízení - pokud se používá interní zrcadlení nebo techniky RAID.

Btrfs mohou zahájit online kontrolu celého systému souborů spuštěním úlohy čištění systému souborů, která se provádí na pozadí. Úloha čištění prohledává integritu celého systému souborů a automaticky se pokouší nahlásit a opravit všechny špatné bloky, které na cestě najde.

Protokolovat strom

An fsync požadavek odevzdání okamžitě upraven data do stabilní úložiště. Fsync-těžké pracovní zátěže (jako databáze nebo virtuální počítač, jehož běžící OS fsyncs často) by potenciálně mohly generovat velké množství nadbytečných I/O zápisů tím, že donutí systém souborů opakovaně kopírovat při zápisu a vyprázdnit často upravené části stromů úložný prostor. Abyste tomu zabránili, vytvoří se dočasný strom protokolů pro dílčí objem do deníku, který bude kopírovat na zápisy spuštěné fsync. Protokoly jsou samostatné, sledují vlastní rozsahy a uchovávají si vlastní položky kontrolního součtu. Jejich položky se přehrají a odstraní při příštím úplném potvrzení stromu nebo (pokud došlo k selhání systému) při příštím opětovném připojení.

Stromy bloků a zařízení

Bloková zařízení jsou rozdělena na fyzické bloky 1 GiB pro data a 256 MiB pro metadata. Fyzické bloky na více zařízeních lze zrcadlit nebo prokládat dohromady do jednoho logického bloku . Tyto logické bloky jsou sloučeny do jednoho prostoru logických adres, který používá zbytek souborového systému.

Kus stromu sleduje tento uložením každé zařízení v něm jako položka zařízení a logických bloků jako kus položky na mapě , které poskytují přední mapování z logické fyzické adresy uložením jejich offsety v řadě významných 64 bitů jejich klíče. Položky kusové mapy mohou být jedním z několika různých typů:

singl
1 logický na 1 fyzický kus
dup
1 logický blok na 2 fyzické bloky na 1 blokovém zařízení
nájezd0
N logických bloků na N≥2 fyzických bloků napříč N≥2 blokovými zařízeními
nájezd1
1 logický blok na 2 fyzické bloky na 2 ze zařízení s blokováním N≥2, na rozdíl od konvenčního pole RAID 1, které má N fyzických bloků
raid1c3
1 logický kus na 3 fyzické bloky z N ≥ 3 blokových zařízení
raid1c4
1 logický blok na 4 fyzické bloky z N ≥ 4 blokových zařízení
nájezd 5
N (pro N≥2) logických bloků na N+1 fyzických bloků napříč N+1 blokovými zařízeními, přičemž 1 fyzický blok byl použit jako parita
nájezd6
N (pro N≥2) logické bloky na N+2 fyzické bloky na N+2 blokových zařízeních, přičemž 2 fyzické bloky jsou použity jako parita

N je počet blokových zařízení, která mají při přidělování bloku ještě volný prostor. Pokud N není pro zvolené zrcadlení/mapování dostatečně velké, pak je souborový systém skutečně nedostatek místa.

Stěhovací stromy

Operace defragmentace, zmenšování a rebalancování vyžadují přemístění rozsahů. Provedení jednoduchého kopírování při zápisu o rozsahu přemístění přeruší sdílení mezi snímky a zabere místo na disku. Aby se zachovalo sdílení, používá se algoritmus aktualizace a výměny se speciálním stromem přemístění, který slouží jako škrábanec pro ovlivněná metadata. Rozsah, který má být přemístěn, se nejprve zkopíruje na místo určení. Potom sledováním zpětných odkazů vzhůru stromem systému souborů dotčeného dílčího svazku se metadata ukazující na starý rozsah postupně aktualizují, aby ukazovala na nové; všechny nově aktualizované položky jsou uloženy ve stromu přemístění. Jakmile je aktualizace dokončena, položky ve stromu přemístění se zamění s jejich protějšky v příslušném dílčím svazku a strom přemístění se zahodí.

Superblock

Všechny stromy systému souborů - včetně samotného stromu bloků - jsou uloženy v blocích, což vytváří potenciální problém se zaváděním při připojování systému souborů. Chcete -li zavést boot do mount, je v superbloku uložen seznam fyzických adres bloků patřících ke stromům bloků a kořenů .

Zrcadla Superblock jsou uložena na pevných místech: 64 KiB do každého blokového zařízení, s dalšími kopiemi na 64 MiB, 256 GiB a 1 PiB. Při aktualizaci zrcadla superbloku se zvýší číslo jeho generace . V době připojení je použita kopie s nejvyšším číslem generace. Všechna zrcadla superbloku jsou aktualizována v tandemu, kromě režimu SSD, který střídá aktualizace mezi zrcadly, aby zajistil určité vyrovnání opotřebení .

Komerční podpora

Podporováno

Již není podporováno

Viz také

Poznámky

Reference

externí odkazy