Jak jsem téměř křivdil Btrfs

8.1. 22:17 | Přečteno: 1586× | Software | poslední úprava: 9.1. 00:31

Na přelomu roků 2025 a 2026 jsem ušetřil pár hodin volného času na otestování přechodu z Ext4 na Btrfs na cca 15 let staré instalaci Debianu (v té době Bookworm) na naštěstí již nepoužívaném notebooku. To nakonec vedlo k ne zcela "krátkému" pátrání po neexistujících chybách a "nepodporovaných funkcích".

Přípravy začaly rychlým pročtením článku How To Convert Ext4 filesystem to Btrfs na Computing for Geeks. Nutné kroky nicméně byly předem jasné, viz níže. Primární chybu jsem možná učinil hned na začátku. Jelikož jsem nenašel LiveUSB s "novějším" LMDE 6, použil jsem pro "btrfs convert" Parted Magic zakoupený roku 2018 s pravděpodobně již notně zastaralou verzí btrfs-progs.

Nutné kroky k migraci z Ext4 na Btrfs:

1. Boot z LiveUSB
2. Brtfs convert
3. Oprava fstabu
4. Reinstalace Grubu z chrootu
5. Reboot

Samotná migrace nakonec proběhla zcela bez problémů a systém nabootoval bez větších potíží. Tedy až na read only filesystem na root partition?! Obsah syslogu příčinu problému nenapověděl, nicméně to je vcelku očekávatelné, když máte syslog na read only oddílu. Podstatu problému jsem naštěstí nalezl ve výstupu dmesg. Tou příčinou byla ... nepodporovaná operace ???

Zde začalo pátraní po chybějící funkcionalitě, která všeumějícímu Btrfs zabraňuje i ve čtvrtině 21. století v nastartovaní systému tam, kde o světelné roky zaostalejší Ext4 neměl nejmenší problém. Jednou z prvních nápověd vyhledávačů bylo mimo jiné to, že v novějším jádře by problém mohl být odstraněn. A protože v recovery modu filesystem fungoval, vyupgradoval jsem již oldstable instalaci Bookwormu na Trixie s jádrem 6.12.57+deb13-amd64 a následně na jádro 6.17.8+deb13-amd64 a 6.17.13+deb13-amd64 z Trixie-backports.

Naneštěstí se i s novějšími jádry chyba dále projevovala, pouze se postupně upřesňoval její výskyt ve zdrojovém C-čkovém kodu Linuxu od toho nejvyššího. Popis chyby se postupně vyvíjel následovně:

BTRFS: error (device sda5: state A) in

• btrfs_finish_ordered_io:3317 errno=-95 Operation not supported
• btrfs_finish_one_ordered:3255 errno=-95 Operation not supported
• btrfs_finish_one_ordered:3195 errno=-95 Operation not supported

BTRFS info: (device sda5: state EA):forced read only

Tyto chyby bohužel nejsou moc dobře zdokumentované, u "nepodporovaných" funkcí to nicméně není zrovna překvapivé. Vyhledávače a AI asistenti dále ukazovali na "podobné" (?) chyby s errno=-5 IO failure (příklad zde), které evokují chybu v hardwaru. Další postupy doporučovaly zkontrolovat device stats a spuštění scrubu problémové partition. Výstup těchto příkazů nicméně vždy značil vše v pořádku.

Ukázka výstupů btrfs device stats a scrub:

# btrfs device stats /dev/sda5
[/dev/sda5].write_io_errs    0
[/dev/sda5].read_io_errs     0
[/dev/sda5].flush_io_errs    0
[/dev/sda5].corruption_errs  0
[/dev/sda5].generation_errs  0


# btrfs scrub start /
Starting scrub on devid 1
scrub started on /, fsid df36c913-d9ee-4fd4-b398-9eb65cfca165 (pid=1304)

# btrfs scrub status /
UUID:             df36c913-d9ee-4fd4-b398-9eb65cfca165
Scrub started:    Tue Dec 30 21:29:14 2025
Status:           running
Duration:         0:00:10
Time left:        0:00:45
ETA:              Tue Dec 30 21:30:11 2025
Total to scrub:   3.84GiB
Bytes scrubbed:   702.82MiB  (17.88%)
Rate:             70.28MiB/s
Error summary:    no errors found

Jak se naštěstí již dříve ukázalo, světelný rok má ve světě souborových systémů délku zhruba jednoho inode a řešení nakonec nebylo tak daleko. Sorry Maxi. :) Nakonec se o žádný problém v Btrfs nejednalo. Problém byl mezi klávesnicí a židlí, možná trochu v samotném chybovém výstupu a potenciálně i ve výše zmíněných btrfs-progs, respektivě v utilitě "btrfs convert".

Na příčinu problému ukázal až výstup příkazu btrfs check /dev/sda5 . Tento příkaz nelze spouštět z připojeného filesystemu, bylo tedy nutné opět nabootovat z LiveUSB. Ukázku chybového výstupu si vypůjčím přímo z blogu learned-today.apz.fi, kde je popsána nejen příčina, ale i řešení celého problému.

Ukázka chybového výstupu btrfs check:

# btrfs check /dev/xvdb1
Opening filesystem to check...
Checking filesystem on /dev/xvdb1
UUID: 8c7512e2-3613-474d-9234-835a57b6f896
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 5 inode 1177668 errors 8000, inline file extent too large
root 5 inode 1177752 errors 8000, inline file extent too large
--- bazillion lines cut ---
root 5 inode 1831684 errors 8000, inline file extent too large
root 5 inode 2878563 errors 8000, inline file extent too large
ERROR: errors found in fs roots
found 7227060224 bytes used, error(s) found
total csum bytes: 6377088
total tree bytes: 159498240
total fs tree bytes: 132104192
total extent tree bytes: 16334848
btree space waste bytes: 40630997
file data blocks allocated: 120313016320
 referenced 6451007488

Jak se na výše zmíněném blogu píše, konvertovat Ext4 na Btrfs nakonec nemusí být až tak dobrý nápad:

I had learned that btrfs created from scratch was pretty decent for some things, but the converted ones wouldn't pass btrfs' fsck even when they would pass online scrub.

Po překopírování systému na čerstvý btrfs oddíl a reinstalaci grubu problém zmizel. Alternativně můžete zkusit poškozené soubory dohledat pomocí jejich inode number a prostě je smazat. To nicméně není proveditelné u systémových souborů, alespoň pokud od systému ještě očekáváte řádné fungování.

rsync -axHAWXS --numeric-ids --progress /mnt/source/ /mnt/target/

V tomto blogu popsaný problém se nicméně nezdá být příliš rozšířený. Příspěvků popisujících stejnou zkušenost, jako jsem měl já a autor zmíněného blogu, se mi totiž nepodařilo dohledat mnoho. Buďto jsme narazili na anomálii, nebo byla příčina opravena (až po roce 2018 ?) v novějších verzích btrfs-progs nebo celého Btrfs. Anebo zkrátka neumím s dnešními "umělou inteligencí posedlými" vyhledávači pořádně hledat.

       

Komentáře

[RealJ]

Btrfs povazuji porad za beta fs. Jakakoliv konverze do btrfs je riziko. Puvodne jsem chtel napsat vice ale bylo by to jenom stezovani si. A jo, spousta lidi a firem btrfs pouziva bez problemu.

[jejda]

Nedávno jsem taky začal experimentovat s btrfs a to hlavně kvůli vestavěné kompresi kterou to umí. Dokáže to ušetřit nějaké místo, které začíná být dneska trochu drahé a taky to šetří opotřebení flash pamětí. Zatím to drží a žádné problémy jsem nezaznamenal, tak uvidíme časem. Na převod starých disků z ext4 na btrfs jsem zatím neposbíral dost kuráže a nejspíš na to ani nedojde.

[⧠ A = 0]

Ano, komprese a deduplikace jsou vlastnosti, kvůli nichž dávám BTRFS od jisté doby víceméně všude. Zvlášť pokud mám velký projekt v několika pracovních stromech a v každém z nich hromadu binárek s ladicími symboly (z nichž každá zabere několik GB), dokážou ušetřit fakt hodně místa.

[jejda]

Deduplikace zní lákavě ale mám disk zašifrovaný pomocí dm-crypt tak myslím že by mě moc nefungovala když btrfs deduplikuje na úrovni bloků.

[Jendа]

No moment, FS je snad až na tom odšifrovaném zařízení.

[jejda]

A jo, to zní logicky. Budu si to muset trochu nastudovat. Asi mě trochu zmátlo to, že "bloky" jsem chápal jako něco, co se zapisuje až na té nejnižší vrstvě. Ale máš pravdu že to tak vlastně vůbec být nemusí.

[Dave]

Aneb jake se to nikdy nema delat.

Podle

https://btrfs.readthedocs.io/en/latest/CHANGES.html

byl v roce 2019 btrfs-progs maximalne ve verzi 4.19.1 a od te doby usel velmi dlouhou cestu do dnesni verze btrfs-progs-6.17.

Takze te priprave jste se moc nevenoval. Stahnou neco aktualniho a dat to na flashdisk zas tak moc dlouho netrva.

[Migi]

Nedal ... Přesne jak v zapisku zmiňuji hned na začátku. Budiž to varováním ostatním.

Nicméně by tvůj komentář šel vyložit i tak, že Btrfs a jeho doprovodné aplikace stále nebyly v roce 2018 Tzv. "Production ready". Což by byl vskutku smutný závěr. :)

[RealJ]

zalezi co chapes pod pojmem production ready, porad jsou tam bugy ktere ti zkurvi data...

[Want]

Anebo zkrátka neumím s dnešními "umělou inteligencí posedlými" vyhledávači pořádně hledat.

Ne. Ty jsi jen nepochopil, že ten FS funguje úplně jinak, než jsi byl zvyklý. Toť vše. Je to tvoje hloupost a zároveň hloupost všech co kladně hodnotili tvůj blogpost. Ale dobře vám tak.

[Migi]

Spuštěním utility btrfs convert přesně k tomu, k čemu je určená, jsme se dopustili "nepochopení funkce FS"? To by chtělo trochu rozvést, nemyslíš?

[Want]

Podobné utility vždycky byly a stále jsou vysoce rizikové, tudíž na hovno. A nikdo normální neriskuje takový proces bez toho, že by si nejdřív odsypal zálohu na nějaké spolehlivé médium. Ovšem když už chceš udělat takovou zálohu, je výhodnější použít nový disk, formatovaný na Btrfs a pak ty disky prohodit - ten původní si ponecháš jako tu zálohu.

Takhle jsem překlápěl původní systém už několikrát a to mám Btrfs v multidevice módu, protože v single módu nad jedním ať už fyzickém či virtuálním blokovém zařízení ho provozují jen kolenovrti, důvěřiví naivkové a magoři.

[Migi]

1) Jasně píšu o nepoužívaném notebooku, takže v tomto případě nebylo třeba zálohovat.

2) Nikde nevidím tu část kde jsme podle tebe údajně nepochopili jak funguje Btrfs ve vztahu ke konverzi z Ext4.

[Want]

Ad 2, hned první věta. O žádném vztahu Btrfs k Ext4 jsem nepsal, protože není. Je to úplně jiný FS s jinou filozofí. Nevím jak ta konverze interně funguje, ale musí to být děsná prasečina. Někde to musí mít uložený ext4 žurnál, minimálně do té doby než se všechna data překlopí a průběžně musí žonglovat s inody. Ad 1 - proč se tedy vůbec o nějakou pitomou konverzi snažíš a nenainstaluješ to od nuly bez interních čuňačin?

[Migi]

Proč mazat systém který spolehlivě funguje už přes deset let. :) Zkoušel jsem to čistě pro to zjištění jak to funguje a jak to dopadne.

[Want]

To jestli je šťáva v zásuvce taky zkoušíš jazykem?

[Migi]

Na to mám přenosné spotřebiče a multimetr. Testování funkcionality a následný debug by měla být přirozenost každého uživatele Linuxu. Proč tě to tak udivuje? Reinstalace jako univerzální řešení na všechno je přirozenost běžného Franty uživatele Windows.

[Maznak]

Rekl bych nazor na veci se meni v case aneb Wantovi je vic nez tobe. Jinak ja bych pouzil radsi NTFS aneb vic nastroju jak z toho dostat data:D A jinak trefnejsi nazev zapisku se mel spis jmenovat "Mazi krivdil jsem ti, zase kamosi?" :D

[Migi]

1) Nevím z čeho usuzuješ věk ať už můj nebo anonyma Wanta.

2) Pokud bych každý problém řešil reinstalací, nikdy bych se nic nenaučil. Kontinuální vzdělávání je v našem oboru vcelku důležitá věc.

3) Nikomu jsem nekřivdil a jestliže chceš problematiku Linuxových FS řešit pomocí NTFS, pak tvuj "trefnější název" minul přinejmenším o několik světelných let. :)

4) Předmětem pokusu s btrfs nebyla záchrana dat ani systému. Pokud bych problém nevyřešil, prostě bych systém smazal a byla by to nulová ztráta.

[Want]

Ad 1. Ty svůj věk, resp. rok narození uvádíš na své profilové stránce a pokud jde o můj anonymní nick, máš pravdu že se může jen dohadovat, ale z kontextu je mu jasné, že určitě nejde o toho joudu, co se mě svými výkřiky snaží diskreditovat. Protože to není první příspěvek co ode mne četl, ví že v tom roce jsem opustil první VŠ a šel na vojnu.

[Want]

Jinými slovy. Jak jsem před lety říkal svým kolegům: "Pánové, cesty kterými půjdete už jsem dávno prošel". Já se učil metodou pokus-omyl, protože jsem se neměl koho ptát. Za dnešních časů tak ztrácí čas, s odpuštěním, jenom vůl.

[Migi]

Takže vzdělávat se jakýmkoliv způsobem je ztráta času, protože nějaký anonymní want už si tou cestou prošel. Testovat software nemá smysl, protože nějaký want už ho mohl dříve testovat. Čert vem opravy.

Tento komentář absolutně postrádá smysl. Zřejmě proto ve svých komentářích tak často prezentuješ vulgární výrazy namísto smysluplných argumentů.

Já "tuhle" cestu prošel a narozdíl od tebe jsem alespoň sepsal kde byl problém a jak ho řešit. Právě proto, aby s tím někdo další neztrácel čas.

[Want]

Vzdělání "jakýmkoliv způsobem" v tvém případě může být klidně i bušení hlavou do zdi. Na "tvůj" problém jsem nikdy nenarazil a je úplně fuk, že jsi to sepsal, protože ten co se bude chtít "učit" stejně jako ty, to stejně nebude číst.

[Migi]

Číst to nemusí. Ale když na stejnbý problém narazí a uvidí v dmesg stejné podivné chyby, vyhledávače ho mohou na tento zápisek nasměrovat a ušetřit mu čas s řešením. A to byla celá pointa tohoto zápisku.

Nechávat si informace pro sebe a dělat anonymně ramena na internetu umí kdejaký hulvát. :)

[RealJ]

diskutovat s Alesem je jako diskutovat se slovakem... ztrata casu... na rozdil od Alese je videt, ze pouzivas rozum. Nekdy se clovek nauci u reseni problemu daleko vice nez reseni toho samotneho problemu a podle me ta cesta stoji za to. Dnesni decka si odpoved na cokoliv vygoogli pripadne jim nejaka LLM rekne... v dobe kdy jsem zacinal byl k dispozici 300 baud modem, bbs, na vse jsi cekal, takze reseni se clovek snazil dopatrat po svem... si pamatuji jak jsem v hex editoru modifikoval nejaky novel netware 3 exac protoze v nem byl bug... o par let jsem se dostal k reseni primo od novelu a krome fixu toho bugu tam udelali par dalsich zmen ktere jsem nemel...

[Want]

Háček je v tom, že už nežijeme v počítačovém pravěku, kde jste ustrnuli.

[RealJ]

ale prosim te, Alesi, kolik skoleni jsi minuly rok mel? Kolik penez jsi utratil na sebevzdelavani? Kolik casu ti tvuj kamrlikovy job dovoli travit vzdelavanim? Ja to shrnu za tebe, uplny hovno, tudiz si se neposunul nikam... uz ani o sendviich nepublikujes, ani prihlasit se ti nechce,...

[Want]

Na posledním školení, kde to dávalo smysl, jsem byl ještě za ÚMOb Ostrava-Jih. VMware a Citrix. A na tom školení od VMware jsem byl jediný, kdo s ním něco dělal před rokem 2000. Na školu jsem byl přijat jako specialista na virtualizaci v linuxovém prostředí a byl jsem jeden z prvních co začali používat v ostrém provozu kvm modul a openvswitch. Proto jsem si také napsal vlastní skript, který na rozdíl od libvirtu tehdejšího libvirtu zvládal živou migraci a neblokuje monitorovací konzoli. Když jsem přišel (2008), tak se pro virtualizaci používal xen. Mimochodem, všechno je to zdokumentované a veřejně dostupné.

Dnes je bohužel situace taková, že školení, která by mi k něčemu byla, nikdo nedělá, protože na to nemá lidi. A na to co dělám školení nepotřebuji. Vystačím si s kolegy. Ty žádné takové nemáš, proto nejsi schopen pochopit v čem spočívá hlavní bonus v zaměstnání na škole jako je ta naše.

[Want]

Že tu nepublikuju? Tak jednak nastalo období, kdy mám obvykle dost jiné práce a druhak od čtvrtka marodím. Držím se zásady raději zalehnout včas, netrousit za každou cenu bacily mezi lidi, a s nudlí u nosu mám chuť leda tak tě setřít jak ten sopel.

[Max]

Já ho nikdy nemažu, maximimálně si ho odleju bokem na jiný disk, když chci předělávat fs, nasaznovat šifrování apod.
Linux na desktop jsem neinstaloval snad 15 let. Stále jedu stejnou instalaci a když mi přibyde zařízení, tak na něj udělám další kopii.
Zdar Max

[Want]

A jak si počínáš v situaci, kdy je systém napaden takovým způsobem, že fakt netušíš kde se skrývá nějaký backdoor?

Podle mne je rozhodující poměr cena/čas. V situaci, kdy si někdo totálně při upgrade rozjebe Ubuntu, je nová instalace nejjednodušším řešením. V případě prastaré mašiny, kdy už balíky nejsou ani v repozitářích, je lepší ten stroj doklepat do času, kdy se už přestane používat.

[Max]

Mám několik zařízení (home pc, pracovní pc a ntb) s pravidelně aktualizovaným Arch Linuxem. Pokud by došlo k průniku a napadení, tak si zkopíruji systém z jednoho z těch dalších zařízení.
Kdybych měl jen jeden systém, dělám si nejspíše zálohy a pak tedy obnovuji ze zálohy. Je rychlejší zkopírovat z jiného hw, nebo obnovit ze zálohy, než zabít celý den instalací a konfigurací.
Zdar Max

[Want]

Tak já na to využívám snapshoty. Nastavit novou cestu je rychlejší než něco kopírovat. Ale pokud máš úplně jiný HW, je lepší začít s tzv. čistým štítem než dumat proč se něco rozbilo a co tomu chybí.

[Max]

Tak snapshoty mám samozřejmě také, ale jen na úrovni storage (v případě serverů), ale to předpokládá, že přijdeš na průnik do konce platnosti těch snapshotů :D, pak už jedině zálohy, nebo čistá instalace, nebo pokud si věříš, tak vlastní inspekce a pročištění. Na úrovni FS ti mohou být k prdu, pokud ti to někdo prolomí. Nic mu nebrání v tom, aby je buď máznul, nebo v nich taktéž změnil obsah, pokud se bavíme o btrfs a ne zfs.
Zdar Max

[Want]

Na úrovni FS ti mohou být k prdu, pokud ti to někdo prolomí.

Ale kdež! Víš jaký je správný postup místo té opičárny s konverzí?

• Nejprve zdrcnu ten ext4
• Na uvolněném místě udělám partici s Btrfs.
• Na ní udělám snapshot do kterého nasypu převáděný systém, upravím zavaděč a fstab
• Rebootnu
• A je-li všechno ok, přesouvám ostatní data - pochopitelně do subvolume kde není systém.
• Nakonec zruším partici s ext4 a roztáhnu Btrfs.

Výhody? Mám původní systém a dál můžu před aktualizacemi využívat výhody snapshotů. Odsypat cokoliv kamkoliv pak už není problém.

[Max]

A já toto nějak rozporuji? Navíc jsme se bavili úplně o něčem jiném, takže tu reakci vlastně vůbec nechápu.
Zdar Max

[Want]

Je nutné pokaždé něco rozporovat? Podle mě ne. Předpokládám, že jsme se shodli na tom, že než používat nějaké obskurní konverzní utility, je lepší využít standardní nástroje.

Já jen popsal jak to dělám, a proč jsou snapshoty výhodné i na úrovni pracovní stanice. Pokud aktualizace klapne, snapshot po nějakém čase zruším. A pokud neklapne, tak se k němu vrátím aniž bych musel něco někam kopírovat. A zruším naopak to co se nepovedlo.

[Migi]

Takze v Btrfs "integrovaná a nativní utilita" se kratce řekne obskurní?

[Want]

"integrovaná a nativní utilita"

Takových obskurních utilit v rámci open source existuje. Prostě si někdo myslel, že by se to mohlo někomu hodit a trochu mu trvalo než si uvědomil, že je to spíš kontraproduktivní produkt, po kterém sáhnou jelita a když to nedopadne podle jejich představ začnou šířit FUD, že je chyba na straně Btrfs.

[Migi]

Pokud je chyba v utilite primo v btrfs-progs, tak to v žádném případě neni "jen nějaký obskurni program" a už vůbec ne šíření FUD o chybách v Btrfs ekosystému. Chyby se objevují v každém softwaru, není na tom nic zvláštního, proto vycházejí nové opravné verze.

[Max]

Jinak dodám, že jsem v životě zažil jen jednu situaci, kdy došlo k průniku do systému a tam jsem to řešil ručním vyčištěním, jelikož šlo o bota bez možnosti další komunikace (bráněno na úrovni fw dmz) s jasným scénářem, co dělá.
Zdar Max

[Want]

Já také zažil takovou situaci, a není to zas tak dávno. Nejdřív jsem nahodil snapshot který prokazatelně nebyl infikován, abych měl čas uklidit a pak jsem nahodil vyčištěnou verzi, s tím že odchytávala a kompletně banovala vše co se pokoušelo využít infiltrované soubory, které už pochopitelně byly tou dobou nahrazeny symlinkem na můj skript. No a pak jsem měl konečně čas na to analyzovat o co se útočník snažil, jakou cestou se tam dostal a jak tomu do budoucna zabránit.

[Erteple]

Inu, jak tu někdo trefně vypisuje: čurák Want.

[Want]

Naraž si na hlavu čepici, ať si tě nepletou s pokladničkou.

[_]

A to jsem si myslel, že největší matlák admin tady je Kapice