Portál AbcLinuxu, 24. dubna 2024 19:22
Stav vydání jádra. Citáty týdne: Mel Gorman, Lars Wirzenius, Greg Kroah-Hartman. Btrfs a vysokorychlostní úložná zařízení.
Současný vývojový kernel je 4.8-rc3 vydaný 21. srpna. Linusova slova: „Vypadá to celkem rozumně, nevšiml jsem si ničeho hrozného.“
Stabilní aktualizace: 4.7.2, 4.4.19 a 3.14.77 byly vydány 21. srpna.
Nejnovější film o Jasonu Bournovi byl dost špatný na to, abych měl čas přemýšlet o tom, jak dávkovat tree_lock při opětovném zamykání.
-Mel Gorman ukazuje, jak se vyvíjí správa paměti
S Linusem jsem často diskutoval návrh systému, ale přímo v práci na jádře jsem se neangažoval (mimo jiné protože spory s Linusem jsou docela stresující záležitost).
-Lars Wirzenius se ohlíží zpět
Chci kód a chci, aby se firma, která ho vyprodukovala, přidala k nám. Zatím se nám to docela daří.
Chris Mason se na severoamerickém LinuxConu v Torontu podělil o zkušenosti svého zaměstnavatele, Facebooku, s používáním Btrfs, a to zvláště ve věci výkonu na vysokorychlostních SSD. Mason byl hlavním vývojářem v dřevních dobách Btrfs, ovšem dnes je jedním z několika správců a Btrfs se za poslední rok dočkalo příspěvků od zhruba 70 vývojářů napříč linuxovou komunitou.
Je členem jaderného týmu Facebooku – jedním z důvodů, proč ho firma chtěla zaměstnat, je zájem používat Btrfs v produkčním prostředí. Z druhé strany, Mason zmínil, že práci přijal, protože měl zájem o právě takové nasazení Btrfs. Jak Facebook uvádí Btrfs do ostrého provozu, přichází se na to, které vlastnosti souborového systému jsou potřeba a co a jak funguje, potažmo nefunguje.
Mason prošel obvyklý seznam vysokoúrovňových funkcí Btrfs, jako jsou namátkou efektivní snímky (snapshots), interní RAID s prokládáním, správa zařízení za chodu, průběžný scrubbing za účelem kontroly na pozadí, zda CRC odpovídají datům v době zápisu, atd. Zrovna CRC dat i metadat jsou vlastností, která jak řekl, Facebook „uchránila před mnoha strastmi.“
Díky kontrole CRC v Btrfs čtení z poškozeného sektoru způsobí chybu I/O namísto vrácení nesmyslných dat. Facebook používal řadu fyzických úložišť, o kterých se zdálo, že v pořádku ukládala data do několika LBA (logical block address), ale jen do restartu systému – po něm už čtení příslušných bloků vracelo pouze data tabulky rozdělení disku (GPT). Výrobce zařízení Mason nejmenoval, protože se ukázalo, že ve skutečnosti šlo o problém BIOS. Každopádně CRC umožnily týmu z Facebooku rychle přijít na to, že problém, který se týkal tisíců strojů po restartu kvůli aktualizaci jádra, nebyl v Btrfs.
Btrfs spravuje oddíly (volumes) v podobě chunků, které obvykle mají 1 GB. Právě díky tomu tento souborový systém zvládá např. RAID se svazky odlišné velikosti. Dané chunky v oddílech mohou být rezervovány pro data či metadata a dají se na ně aplikovat různé úrovně RAID (např. RAID-1 pro metadata a RAID-5 pro data).
Btrfs ovšem měl problémy se soupeřením o zámky a některé z nich podle Masona stále zůstávají, přestože se na zlepšení pracuje. Souborový systém je optimalizován na použití na SSD, ale když Mason spustil benchmark fs_mark ve virtuálním stroji (aby získal čísla ne absolutní, nýbrž jen pro srovnání), zjistil, že XFS za sekundu zvládl vytvořit zhruba čtyřikrát tolik (33 tisíc oproti 9 tisícům) souborů s nulovou délkou. To „nebylo dobré,“ ale Mason chtěl, aby XFS fungoval co nejlépe.
Proto se podíval, na co XFS narážel – byly to zámky pro alokaci objektů souborového systému. Dokázal tak zvýšit výkon XFS až na 200 tisíc vytvořených souborů za sekundu tím, že při vytvoření souborového systému zvýšil počet alokačních skupin (ze čtyř na šestnáct, což odpovídalo počtu CPU v testovacím systému). Pak už byly největší brzdou CPU a pomocí volby mkfs už nešlo snadno dále zlepšovat výsledky.
Potom se pustil na Btrfs. Díky perf si všiml soupeření o zámky B-stromů. V Btrfs ukládají B-stromy všechna svá data do listů. Při aktualizaci stromu je nutné na cestě k příslušnému listu zamknout všechny vnitřní uzly počínaje kořenem. Při některých operací nezbývá než udržovat při průchodu stromem uzly zamknuté. Naštěstí pouze list opravdu musí být zamknutý, ale neplatí to vždy a protože se se zamykáním začíná v kořeni, soupeření není úplně překvapivé.
Aby zkusil Btrfs zrychlit, použil pododdíly (subvolumes) k vytvoření více kořenových uzlů. Místo obvyklého jediného oddílu (s jediným kořenem) tak vytvořil 16 pododdílů (pro každý CPU jeden) s vlastními kořeny a zámky. Tím se Btrfs přiblížil výkonu XFS a dosáhl 175 tisíc vytvořených souborů za sekundu.
Cílem ovšem bylo souborový systém zrychlit bez uchýlení se k pododdílům, a tak vzniklo nové schéma zamykání uzlů v B-stromu. Ve výchozím stavu má Btrfs 16KB uzly, což se nemění, ale nově je každý uzel rozdělen mezi 16 skupin, které mají vlastní zámky.
Mason se zatím nerozhodl, jaký počet skupin pro každý uzel je optimální, nicméně změna jako taková umožňuje jinak výchozímu Btrfs vytvořit 90 tisíc souborů za sekundu. V Btrfs se na mnoha místech předpokládá, že uzlu odpovídá jen jeden zámek, a pracuje se na tom, aby tato podmínka zmizela. Navíc Btrfs před časem přešel na zamykání čtenářů/písařů, což se ukazuje být další brzdou. To je další námět k testování.
V některých jiných ohledech ale Btrfs výkonově XFS překonává. XFS v testu zapisuje 120 MB/s a provádí 3000 IOPS (vstupní/výstupní operace za sekundu), zatímco Btrfs zvládá tutéž práci při 50 MB/s a 300 IOPS, takže podle Masona Btrfs zvládá úkoly organizovat lépe a s méně I/O operacemi.
Ve Facebooku je vytížení Glusteru, který využívá rotační úložná zařízení, extrémně citlivé na latenci přístupu k metadatům, a to až tak, že vysoká latence jediného uzlu může výrazně zpomalit celý cluster. V minulosti se ve firmě používala flashcache (podobná bcache) pro jak XFS, tak i Btrfs, aby kešovala některá data a metadata na SSD. Tím se sice latence metadat zlepšila, ale ne dostatečně.
Proto má Mason sadu patchů, které automaticky ukládají metadata Btrfs na SSD. Bloková vrstva poskytuje informaci, zda je úložiště rotační… prozatím patch předpokládá, že úložiště je rychlé, pokud není rotační. Výsledkem jsou veliký rozdíl v latenci a poměrně malé nároky na flash úložiště (např. 450 GB pro 40TB souborový systém) v případě zátěže, s jakou se setkávají ve Facebooku, kde jde o pestrou škálu velikostí souborů. Mason dodává, že „metadat budete potřebovat o poznání víc, pokud máte samé 2KB soubory.“
Sada patchů je malá (přidává 73 řádek kódu), což je podle něj fajn. Není ovšem úplně hotová, protože btrfs-utils budou vyžadovat nějaké změny, aby ji podporovaly. I tyto změny by ale měly být podobně malé.
S dalším úzkým hrdlem se setkal při používání příkazu trim (nebo discard), aby upozornil SSD na bloky, které souborový systém již nepoužívá. Překladová vrstva flash by pak mohla příslušné bloky ignorovat při úklidu (resp. garbage collection), a tak by se teoreticky zlepšil výkon. Jenže v praxi je řada zařízení pomalá při zpracování příkazu trim. XFS i Btrfs si udržují seznamy bloků, na které je trim možno použít, pak je odešlou v podobě příkazu, na jehož dokončení čekají během transakcí, což zase zdržuje operace souborového systému samotného. Výsledné zdržení může být značné, podle Masona až „desítky sekund.“
Ric Wheeler se ozval s tím, že trim je pouze požadavek, který úložné zařízení může ignorovat. Navrhl nepoužívat ho během běžných operací souborového systému. Ted Ts'o souhlasil a dodal, že v ext4 a možná i dalších souborových systémech je dobrým zvykem pravidelně dávkově spouštět trim (fstrim) z cronu.
Mason odpověděl, že nevýhody nepoužívání trimu jsou závislé na konkrétním zařízení. V některých případech se tím může zkrátit životnost zařízení nebo zvýšit latence při úklidu (garbage collection), ale také se nemusí stát vůbec nic. Wheeler upozornil, že při použití thin provisioning může absence trimu vést až vyčerpání volného místa na zařízení, ačkoli ve skutečnosti je místa dost.
Přestože nejde o záležitost specifickou pro flash úložiště, vyskytly se nějaké potíže s velkými (> 16TB) instancemi souborového systému Btrfs právě kvůli kešování volného místa. Původně nebyly volné extenty sledovány vůbec, takže celý souborový systém musel být prozkoumán při připojení – což bylo pomalé. Po přidání sledování volného místa cache sloužila pro skupiny bloků a velké souborové systémy měly mnoho skupin bloků, takže při každé transakci se více kešovalo. V jádře 4.5 přidal Omar Sandoval novou cache pro volné místo (šlo ji povolit pomocí -o space_cache=v2), která přinesla „dramatické zrychlení“: latence transakcí spadla ze čtyř na nula sekund.
V dohledné době Mason plánuje dokončit nový mechanismus zamykání B-stromů a zapracovat na úzkých hrdlech fsync(), ačkoliv si myslí, že nová cache pro volné místo s tím pomůže. Chce se také podívat na některé další spinlocky, které stojí za horším výkonem.
Zmínil několik nástrojů, které používá k hledání úzkých hrdel. Perf je ten pravý nástroj, pokud je příčina zpomalení svázána s CPU, ale je o poznání těžší najít příčiny blokování. K tomu doporučil BPF a BCC. Zvláště skript BPF offcputime Brendana Gregga je užitečný k sledování stavu zásobníků jak jádra, tak aplikací, čímž pomáhá najít příčiny blokování procesu. Facebook má dokonce offcputime tak rád, že další správce Btrfs Josef Bacik vytvořil metodu agregace výstupu programu z více systémů.
Na závěr přednášky padlo několik otázek. Kdosi se zeptal, zda Mason zaznamenal nějaký trend v nasazování Btrfs na menších zařízeních. Mason na to řekl, že souborový systém si za chodu žádá láskyplnou péči, což je ostatně důvod, proč se mu Facebook věnuje. Aby se Btrfs na ARMu této péče dostalo, pokračoval Mason, musel by se mu věnovat někdo se zkušenostmi s ARMem.
Další otázka padla na to, jak moc se ještě Btrfs může zrychlovat. Mason se tvářil celkem optimisticky se slovy, že Btrfs může být „ještě mnohem rychlejší.“ Formát metadat je flexibilní, takže „pokud je něco rozbitého, můžeme to spravit.“
Poslední dvě otázky mířily na dva různé testy, z nichž oba jsou zajímavé, ale ani jeden Mason nezkoušel. Myslí si, že srovnání flashcache a bcache by nejspíš poskytlo podobné výsledky a flashcache se ve Facebooku úspěšně používala, takže nebyl důvod zkoušet i bcache. Ani srovnání s ZFS nezkoušel, protože v začátcích Btrfs nebyl ZFS k dispozici – dnes už tento důvod pominul a Masona samého by výsledky zajímaly.
[Autor článku, Jake Edge, děkuje Linux Foundation za pomoc s cestou do Toronta na LinuxCon North America.]
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.