Eida.cz - Trilobajty

Je to téměř jako včera, kdy jsem vytvářel první strukturovaný LVM layout pro srdíčkový systém, tehdy se seběhlo spoustu nesmyslných windowsích komentářů a croissant. Ale teď je budoucnost, rok 2025, není to depresivní, ale je už úplně běžné, že manažery logických svazků jsou už dávno součástí běžných souborových systémů, máme kapsy na APFS, btrfs nám dospěl a vlastně všude jsou paralelně dostupné SSD nad PCIe rozhraními. Přesto pořád ještě nemáme dobu, kdy by se dalo nějak snadno a rozumně levně kupovat obrovské množství místa na solid-state discích, takže ve finále pořád zůstáváme svými jádry u rotačních SATA úložišť, protože si je prostě dovolit a mít je a smát se s nimi.

Je květen, už je to 50 000 hodin od nákupu enterprise UltraStarů. Je nutné se podívat do té doby, kde RAIDy stále jely nad mdraid a přestože první komerční NASky už dodávaly btrfs jako default, bylo stále jednodušší operovat na klasických a osvědčených XFS a JFS. Jenže původní JFS pro AIX vznikl někdy na samém začátku 90. let, takže je to už trochu dinosaurus. V té době se rozhodně nepočítalo s tím, jak budou technologie budoucnosti pracovat, zejména tedy zase Apple TimeMachine. Ten funguje, díkymoczato, už ho umíme spolehlivě používat kdekoliv, ale jaksi nám to celé přerostlo přes hlavu a časové kapsy díky svým diff zálohám způsobují, tedy alespoň na multipurpose uložišti, opravdu pekelnou fragmentaci.

A protože žijeme v bublince, která dávno opustila x86 a vládne tu armv9 s 16k stránkami, nedává vůbec smysl v klasickém JFS a mdraid pokračovat. Je čas přejít na btrfs a všechno zoptimalizovat. A to tak, že pořádně. Při takových operacích se často může zastavit dech, protože existují vlastně dva způsoby – buď se stávající pole kompletně za běhu replikuje na pole nové, nebo... se to zkusí na tom samém poli, kde je filosofie poměrně přímočará – jeden disk se failne a vyjme, vytvoří se na něm degradovaný btrfs savek, na něj se rsynce obsah z druhého disku, ten se po dokončení taky zruší, přidá se do btrfs v režimu raid1 a provede se synchronizace. Zní to... snadno, žejo.

První mentální zádrhel při variantě převodu na místě samozřejmě spočívá v tom, že by se aktuální pole dobrovolně převedlo do degradovaného stavu a neposkytovalo by po nějakou dobu, pod zátěží, svou funkci. Hups viď, pokud by došlo zrovna k nějaké apokalypse, kyberútoku, nebo jen obřímu dešti s kroupami. Naštěstí extended SMART test ukázal, že prakticky není čeho se bát, že jsou disky v naprosto top stavu – když se vezme v úvahu, že nejsou pro běžné, ale pro enterprise použití, pak se to dá asi risknout, poměrně s pohodlím. Když tady shrnu wokflow jako celek, pak je to docela jasné: v první řadě se udělá SMART extended test, který musí skončit bez chyby. Pokud se tak stane, asi se dá první disk z pole odebrat.

Tohle zabere pár hodin, výsledky budou pak k dispozici v reportu SMART pod provedenými testy, což lze vyfiltrovat jako

Pak by bylo asi super si taky udělat zálohy pole a případě info o tom JFS jako takovém, tj. vypsat si detaily a uložit si je do krabičky

No a pokud je všechno v pořádku, pak tedy nezbude než se nadechnout a skočit... což tedy znamená z pole vyjmout jeden z disků a vyčistit na něm superblok, aby nebyl už součástí pole:

Potom už tedy dle plánu stačí vyrobit nový btrfs a na něm odpovídající subvolumes, pokud to má sloužit nějakému konkrétnímu účelu. Tohle je docela magie, zatím experimentuji s tím, že časová kapsa bude mít subvol=@timemachine, nossd ,noatime, compress=zstd, space_cache=v2, autodefrag, obecně kompresi a autodefrag zkusíme i u často měnících se zápisů, naopak úložiště nebude mít CoW a zálohy z podstaty vlastní komprese nepotřebují komprimovat. Pokud tohle všechno projde, pak je ale potřeba napodobit mountem původní strukturu, aby mohl proběhnout rsync

A tady se ukáže. Tyjo. Už je to druhá noc, co to běží. Démoni kvílí, diskové hlavičky kmitají. Během toho se mi mimoděk povedlo taky přenést na Windows servery nějaká data záloh, dohromady přes 350 GB, a to pomocí SCP vestavěným windowsím OpenSSH. Kdo by tohle čekal. Je to hlavně kvůli tomu, že rsync spustit směrem ven nešel, ale tohle bohatě stačí. Cílový disk je stejně na nějaké zašité NAS a je připojení fileserveru přes iSCSI. Všechno je to rychlé a krásné.

Lokální rsync kopíruje všechno včetně xattr a acl z původního do nového umístění, na tom asi není co popisovat. Hrozná legrace ale probíhá v posledních hodinách, kdy se přenáší časová kapsa z MacBooku. Interní struktura časové kapsy je tu rozdělená na několik tisíc 256MB bands. Během sledování až tady doško k tomu, kdy začal rsync poměrně divoce jančit a obvyklá rychlost rapidně spadla z nějakých průměrných 250 MB/s na 1.5-10 MB/s, v závislosti na jednotlivých souborech s inkrementálními zálohami. Tady je na tom hrozně krásně vidět ta absolutní a totální fragmentace, která neskutečně zpomaluje časovou kapsu. Je dost možné, že tohle jsme dřív nebrali do úvahy kvůli tomu, že většinou existovala taková kapsa pouze jedna; teď jich je ale několik, do toho běží ještě pravidelné záznamy, jiné zálohy, skokové zápisy během zálohování na kapse, prostě dochází k souběhu, takže data skáčou přes sebe a padají jako dýně do trávy.

Není to nic neočekávatelného, koneckonců fragmentace byla běžná na točivých discích. Co mě ale překvapuje, že vlastně JFS nemá žádné jednoduché nástroje, jak se s tím vypořádat. Po zkoumání tedy uvidíme, jestli CoW a nastavení autodefrag reálně něco zmůže, ale i kdyby ne, btrfs dovede velmi dobře monitorovat, v jakém stavu data nakonec jsou, včetně absolutní míry frgamentace.

Ještě to není, ale když skočím o pár hodin dopředu, pak dalším krokem bude ještě jedna kontrola, zda se povedlo ze starého disku synchronizovat vše – buď lze ověřit velikosti, nebo nechat znovu projet rsync, koneckonců ráno se uložila jedna malá záloha navíc. Ale až to nastane... bude čas na převod druhé disku, což tedy bude zahrnovat jeho odpojení a zastavení celého pole, vymazání superbloku a přidání tohoto disku do stávajícího btrfs, kde pak proběhne konverze na raid1 režim. Tohle nelze provádět na úrovni subvolumes, ale na celém svazku.

A asi by bylo i vhodné to kontrolovat a na závěr ověřit

Potom už asi bude všechno připravené a může se to zapsat do fstab a najet do ostrého provozu. Zatím je to jen přání a otázka budoucích několika hodin. Opravdu bych nerad, kdyby se tu pak zvrhlo zas v nějaké trilobajty, protože tohle je prostě způsob, jakým se dá fungovat na dnešních technologiích – čistě a svobodně.