Portál AbcLinuxu, 10. ledna 2026 05:19
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:
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
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.
Tiskni
Sdílej:
včera 16:59
⧠ A = 0 | skóre: 11
| blog: Technokratovo_zrcadlo
| Helsinki
včera 17:15
Migi | skóre: 59
| blog: Mig_Alley
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.
včera 22:52
Migi | skóre: 59
| blog: Mig_Alley
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.