Jak jsem téměř křivdil Btrfs

včera 22:17 | Přečteno: 359× | Software | poslední úprava: dnes 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.

[dnes 15:49 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.