Přechod na Btrfs aneb Co s volným časem v lázních

19.7.2024 22:35 | Přečteno: 1386× | Volný čas

O přechodu z ext4 na Btrfs jsem uvažoval už nějakou dobu. Pročítal jsem různé články, poradnu na AbcLinuxu a následné diskuse, některé hodně bouřlivé. Nakonec jsem usoudil, že změna by byla užitečná, ale ne zcela jednoduchá. Takže se mi za běžného provozu nechtělo zasahovat do fungujícího stavu, protože na řešení případných vzniklých problémů bych nemusel mít dost času. Ale když mi doktor doporučil lázně, začaly se úvahy měnit v reálné plány.

Na začátku považuji za nutné uvést, že jsem člověk značně konzervativní a v rozporu s Murphyho zákonem se snažím zachovat systém (nejen OS), který se osvědčil, pokud mě nic nenutí ke změně. Například mám už víc než 12 let stejný desktop na pracovním počítači v kanceláři. Na druhou stranu se mi několikrát stalo, že změna, do níž se mi moc nechtělo, měla nakonec pozitivní výsledek. Typickým příkladem byl přechod z Pascalu na C, o čemž jsem se zmínil v některém z předchozích blogů, nemluvě o přechodu z Windows na Linux zhruba před dvaceti lety.

Změna FS se netýká onoho pracovního počítače v kanceláři, ale pracovního notebooku. Jedná se o deset let starý ThinkPad, který mi v práci pořídili před sedmi lety jako repasovaný. Má procesor i5-4300U na 1,9GHz, 8GB pamětí, 230 GB SSD. Před třemi lety mi na něm vyměnili display a letos v zimě baterku, jinak šlape celou dobu jak hodinky. Hned od začátku na něm mám ArchLinux, který jsem v době pořízení už několik let používal.

Disk jsem tehdy rozdělil na 3 oddíly: jeden malý pro /boot, něco přes 30 GB pro kořen, zbytek pro /home. Kdysi jsem četl něco o tom, proč je dobré mít samostatný oddíl pro /boot, od té doby to používám. Je možné, že ty důvody pominuly, ale jak jsem předeslal, jsem člověk konzervativní. Samostatný /home jsem několikrát ocenil při změně linuxové distribuce. Ale z toho, co jsem přečetl o Btrfs, jsem naznal, že subvolume udělá stejnou službu.

S přibližujícím se termínem nástupu do lázní jsem zintenzivnil přípravy: kromě opětného pročítání různých informačních zdrojů jsem si připravil USB s live ArchLinuxem, potřebnou techniku pro zálohování a také pro záložní zálohování, jelikož jsem si jistější, když mám připraven i nějaký "plán B". (To mi připomíná prohlášení šéfa jedné dopravní společnosti, když začaly opravy D1 na trase Praha - Brno: "Máme zmapovány objízdné trasy a objízdné trasy objízdných tras.") Takže jsem si nachystal starší 1,5 TB interní SATA disk, který se nám doma povaloval, k němu samozřejmě USB interface, a externí 200GB SSD disk. Na ten interní disk jsem si nahrál i nějaké filmy (pár set GB dat, nechtělo se mi ztrácet čas vybíráním), kdyby lázeňská zábava vázla.

Do lázní jsem dorazil v pondělí. První dva dny jsem se zabydloval a snažil zorientovat v lázeňském prostředí, ve středu odpoledne po procedurách a po večeři (poněkud matoucí název pro jídlo v 16:40) jsem zahájil akci. Plán byl následující: oddíl s /boot nechat, jak je (Andrej by asi nesouhlasil), zálohovat všechna data, /home pro jistotu dvakrát na dva různé disky, pak oddíl s /home zrušit a kořenový oddíl zvětšit na veškeré dostupné místo na disku, převést ho na btrfs, udělat subvolume pro /home a potom do něj nakopírovat zpět data ze zálohy. Možná to jde udělat i jinak a líp, ale plán mi připadal reálný. Z tohoto článku jsem věděl, že konverze z ext4 je možná, jen jsem netušil, jestli bude lepší nejdřív oddíl konvertovat a pak zvětšit, nebo naopak. Ale doufal jsem, že to zjistím, až to zkusím. "Plán B" pro případ, že by konverze nevyšla, byl udělat čistý oddíl a do něj nakopírovat data, no a "plán C" v případě jeho selhání by znamenal novou instalaci systému.

Nejdřív jsem vyzkoušel konverzi na onom 1,5 TB disku. Kdyby to nedopadlo, tak bych maximálně přišel o zmíněné filmy. Protože jsem ještě jednou procházel návody všechno znovu kontroloval, začal jsem s tím až po deváté hodině večer. Navíc první pokus skončil chybovým hlášení, které se týkalo problému s reiserfs. Naštěstí to vyřešila instalace balíčku reiserfsprogs. V deset to ještě nebylo hotovo, takže jsem šel spát s tím, že do rána uvidím.

Ráno jsem omrknul výsledek, vše vypadalo v pořádku, tak jsem spustil btrfs scrub a šel se nasnídat. Po návratu jsem byl ovšem poněkud zklamán, po půl hodině neměl zkontrolováno ani 10 procent. Takže jsem to stopl v naději, že FS je v pořádku, spustil live distribuci a šel dělat zálohy. (Až později mě napadlo, že jsem mohl zkusit ještě btrfs check.) Na velký disk jsem hodil obrazy všech oddílů, na externí SSD jsem nakopíroval data z domovského adresáře, přičemž jsem některá méně důležitá vynechal. To zabralo skoro celý den, probíhalo to tak, že jsem spustil kopírování nebo program dd, šel na proceduru nebo na jídlo, po návratu zkontroloval stav a případně spustil další fázi zálohování.

Večer bylo vše hotovo. Zkusil jsem konverzi oddílu s kořenem, výsledkem bylo hlášení o nedostatku místa. Nebylo mi zcela jasné, jestli se jedná o místo v oddílu nebo by mohlo být i jinde na disku, takže jsem smazal oddíl s /home, ale pokus o konverzi skončil stejně. Ta se podařila až poté, co jsem zvětšil oddíl na maximum. Proběhla poměrně rychle, stejně tak rychlá byla i následná kontrola pomocí btrfs scrub. Předpokládám, že kromě menší velikosti disku hraje v tomto směru roli i skutečnost, že se jedná o SSD disk. Pak jsem vytvořil subvolume /home a spustil obnovu dat. Připojil jsem zálohovaný image a na kopírování použil rsync. Tohle jsem si možná mohl trochu líp promyslet, ale už bylo dost pozdě a chtělo se mi spát. Zpátky se tak nakopírovala spousta zbytečného smetí, např. cache webových prohlížečů, ale řekl jsem si, že do rána to bude hotové a šel spát.

Druhý den ráno, což bylo vlastně dnes, jsem se vzbudil trochu dřív, kopírování bylo hotovo, tak jsem spustil znovu btrfs scrub a přemýšlel, co dál. Jasně, nastavit správně UUID a typ FS v fstab. Změnu jsem provedl, počkal, až doběhne btrfs scrub (jen celkem šest a půl minuty) a zkusil nabootovat. (Uznávám, bylo to hodně ukvapené.) Pokus skončil hlášením "unknown filesystem type 'btrfs'". Napadlo mě, že můj zásah do fstab nebyl košer, takže jsem nabootoval live verzi, připojil disky a vytvořil fstab pomocí genfstab. Další pokus o boot - stejný výsledek. Spustil jsem live distribuci a chvilku pátral na internetu, ale pak už jsem musel jít na snídani, tak jsem počítač vypnul.

U snídaně mě napadlo, že to možná nebylo hlášení operačního systému, ale Grubu, takže mi hned došlo, že jsem neaktualizoval příslušný konfigurační soubor. Po snídani jsem měl hodinu čas do první procedury, takže opět live distribuce, připojení disků, arch-chroot a grub-mkconfig. A pro jistotu update systému - aktualizovaly se myslím jen tři baličky, mezi nimi i linux. A další pokus se stejným výsledkem, další pátrání. Při tom jsem náhodou narazil na radu, jak se dostat do položek v menu Grubu, což jsem sice nepotřeboval, ale napadlo mě spustit kernel linux, běžně totiž používám linux-lts. Jaké bylo mé překvapení, když systém naběhl tak, jak jsem býval zvyklý.

Jasně, při instalaci nové verze jádra se vytvořil nový soubor initramfs, ve kterém je patrně informace o upraveném FS, která v původním nebyla. (Doufám, že ten, kdo ví, jak to skutečně funguje, se jen shovívavě pousměje.) Takže jsem ještě z live verze reinstaloval linux-lts (asi by stačilo pustit mkinitcpio, ale nechtělo se mi zkoumat parametry) a už vše běželo jako dřív.

Po návratu z dopoledních lázeňských procedur jsem disk znovu otestoval, promazal nějaké zbytečné soubory, vyzkoušel nějaké příkazy dávající informace o FS. Vše fungovalo, jak má. A jelikož odpolední páteční procedury skončily brzo, napadlo mě všechno zapsat, dokud to mám v paměti. Možná někomu připadá, že jsem objevil Ameriku, no co už.

PS: Omlouvám se za dlouhý zápis, ale neměl jsem čas na krátký .

       

Komentáře

[jejda]

Proč nešifruješ? Já teď zrovna špekuluju jaký filesystém a bootloader dát na novou usb flešku s linuxem. Na staré mám syslinux, fat32 /boot a zbytek luksem zašifrovaný / s ext4. Sice to funguje, no blbý je, že když tu flešku strčím do mašiny kde je uefi, musím lézt do biosu a přepínat legacy mode a přegenerovávat initramdisk. Chtěl bych aby mě to bootovalo všude, takže asi potřebuju něco jak hybridní MBR? Taky si pohrávám s myšlenkou jestli tam nedat bcachefs. Ten umí na rozdíl od btrfs nativně šifrovat. Na druhou stranu si ale zas říkám že když nepoužívám snapshoty a raid, tak mi přechod z ext4 na nějaký moderní filesystém vlasně nic moc nepřinese. Tak nevím.

[Vtipnéř]

Nešifruju, protože jsem nikdy na počítači neměl věci, u kterých by vadilo, kdyby se dostaly k někomu cizímu.

S tou univerzální bootovací fleškou ti asi neporadím, ale letmo jsem zkusil google, nějaké návody na mne vyskočily.

Snapshoty a raid taky zatím nepoužívám, ale o snapshotech vážně uvažuju. O tom, jestli mi přechod na btrfs něco přinese, jsem taky přemýšlel, nakonec převážila lepší kontrola dat. Sice jsem se u ext4 za celou dobu nesetkal s chybami, ale možná to bylo proto, že jsem se o nich nedověděl.

[...]

se ZFS se casto pouziva zfs-auto-snapshot, cron task, co udrzuje nakonfigurovanej pocet minutovych, hodinovych, dennich, tydenich, etc. snapshotu, podle libosti - koukam, ze pro btrfs existuje analogicky btrfs-auto-snapshot; snapshoty nad CoW FS jsou "zadarmo", tohle si o nasazeni IMHO vylozene rika :)

[Milan Uhrák]

distribuce jako openSuse snapshotují automaticky před updatem ( možná i před "ruční" instalací čehokoliv ). Snapshotují se jen některé systémové subvolumy, /home ne.

[k3dAR]

uni flash pro legacy i uefi delam tabulka GPT, prvni oddil 2MB s priznakem bios_grub (btw: neformatuje se na nic), druhej oddil EFI (format FAT32) a nainstaluju na to Grub jak grub-pc (ten s GPT leze prave do toho prvniho bios_grub oddilu) tak grub-efi (ten leze do EFI oddilu)...

[4ntik3dAr]

Instalujes leda hovno na ext2. Jsi zas neco vygooglil a delas ramena. A zapomnel jsi uvest ze mas xubuntu na lenovu.

[X]

Nemohl by jsi hejtovat i moje prispevky? Proc jenom k3dAR?

[k3dAR]

jj, vygooglil sem si to... treba tento druhy vysledek z roku 2018

[Valgrind]

Lazne si platis sam, nebo je to na pojistovnu?

[Vtipnéř]

Je to na pojišťovnu.

[artnat]

Holky v laznich maji zasadne bobry.

[karkar]

Lázně to jsou taková bobří farma, nebo lépe možná spíš bobří chovná stanice.

[ůkasjojsaoias]

přeji příjemný pobyt.

Díky za článek!

Nepochopil jsem asi jen, proč jednou

btrfs scrum

trvalo 10 % 30 minut a potom 6 minut.

[Vtipnéř]

Poprvé jsem zkoušel funkčnost btrfs scrub na tom zálohovacím disku, což je starší 1,5 TB plotnový disk, zaplněno jsem měl asi 500 GB. Podruhé to bylo ověření výsledku na disku v notebooku, což je 220 GB SSD disk. Myslím, že obojí (velikost i způsob uložení dat) hraje roli, možná i to, jestli je to disk interní nebo připojen přes USB.

Jirka

[nezbednice nezbedna]

Delal jsi nejaka mereni rychlosti s ext4 a pak s btrfs?

Ja bych cekala, ze s btrfs bude na tomhle zeleze spousta veci o poznani (treba i nasobne) pomalejsi. Samozrejme je to dan za "safety" (nekamenujte me - ano, vim, ze btrfs nema stale punc "enterprise safety").

Ja zustavam u ext4, protoze i hloupa sqlite (pouzivana beznymi desktopovymi aplikacemi) tam bezi o dost rychleji.

[...]

co to jsou, tyhlety mereni rychlosti? takovy to, ze si rozbalim linuxovej source a pak koukam, jak rychle ho to smaze, aniz by se na tom systemu delo neco dalsiho?

[...]

ja jen, ze podle takovejch cislicek porovnavat filesystemy, mno, to pak dopada presne tak, ze lidi nechapou, kdyz jim ukazu vyladenej MySQL server nad ZFS, kterej tezi z kvalit prefetche, async linearniho zapisu a hlavne, z mocnyho cachovani... ze takovej ficak jeste nevideli jakoze takovy nejaky poradnejsi testy nevidim nikoho delat, maximalne tak ty souborovy operace, single thread, single user...

[Vtipnéř]

Delal jsi nejaka mereni rychlosti s ext4 a pak s btrfs?

Nedělal, nepotřebuji žádné rychlé zpracování velkých dat. A když už někdy kopíruji velké soubory, tak myslím, že rychlost je dána hlavně rychlostí připojení.

Jirka

[k3dAR]

s konverzi si mel bud stesti, nebo to uz neni problemove, nebo to problemy s konverze jeste prijdou

ma prvni spatna zkusenost s BTRFS byla prave kdyz sem delal konverzi z ext4 na btrfs (je to uz par let) a nasledne to dalsi den zkolabovalo :) , coz mi nasledne v ruznych vlaknech bylo fanouskama BTRFS "vysvetleno" ze je prave diky konverzi ktera mela(ma?) masarky...

[uzel]

A co holky v laznich? Co tak jit vecer na tancovacku?

[Alfik]

Mám dotaz je na brtfs nějak dořešeno pořádně šifrování na notebooku vs uspávání do ram/ běžící zamknutý stroj? Jde mi o to, že mám na notebooku šifrování, ale tak nějak je zřejmě k ničemu, jelikož to vypadá, že je to zašifrované pouze když je celý vypnutý? - Zatímco většinu času notebook spíše jede/nebo je ve spánku.

Zatím to řeším tak, že důležité věci šifruji ještě přes gpg - ale to je problematické.

Našel jsem nějaký fscrypt (něco takového se prý používá na androidu) to je pro ext4 a umí to šifrovat konkrétní věci, když se nepoužívají. Akorát to má zásadní problém - zřejmě to nejde zálohovat, když je to zašifrované (pěkně blbá vlastnost)

Jak tohle řešíte - když stroj běží, ale potřebujete věci, co se nepoužívají mít zašifrované?

[takurcite]

Ta data nejsou sifrovana jen ve vypnutém stavu. Tvůj systém tě při startu požádal o klíč, tudíž je schopný sifrovana data zdánlivě zobrazit v korektní formě právě pomocí toho klíče.

[k3dAR]

obecne... bezici nezamknuty logicky nevim jak bys chtel chranit pokud ty data mas na odemknutem disku, leda mit dalsi oddil ci image-soubor kterej bys mel sifrovanej zvlast a odemknul jen pro pripad pristupu a pak zase zamknul...

druha vec je kdyz je nb suspendnutej, prave proto pouzivam hibernaci, protoze se nechci spolehat na loginmanager/lockscreen s odemcenym diskem... matne si vybavuju pred lety sem zahlid nejde PoC ze pred suspendem bys hodil do ram mini system ala initramfs, na nej se chrootnul, zamknul disk a pri resume v obracenem poradi...

[k3dAR]

tady je zda se ten PoC realne zprovoznitelnej pro Arch...