Poslední příspěvky1
Software / Re:Nekorektní chování BTRFS
« Poslední příspěvek od Miroslav Buček kdy Dnes v 12:32:07 »Je to klasická btrfs ENOSPC past, ne „mystická“ chyba.
Co se stalo:
1. Došly metadata, ne data.
Metadata, RAID6: total=134.62GiB, used=134.11GiB (99.63%) – tedy metadata plná. Když jsou metadata plná, btrfs přestane zapisovat a remountne se RO, i kdybys měl ještě stovky GB v Data. Proto zároveň vidíš:
space_info DATA has 131499511808 free, is full – to znamená „uvnitř datových block group je pár volných děr, ale já z nich teď nic neudělám“, ne že je disk fyzicky plný.
2. Btrfs si v tu chvíli už neumělo vytvořit nový metadatový chunk.
Aby si mohl přidat 1GB metadat v RAID6, musí mít nealokovaný prostor na zařízení. Ty jsi měl všechno alokované do datových chunků, takže nebylo kam ten nový metadatový chunk dát. Proto ti i balance na začátku spadl s No space left on device.
3. find ti zapisoval.
Říkáš „read-only úloha“, ale na btrfs (a u 42M souborů zvlášť) to není čisté čtení – aktualizuje se atime / relatime a tím se zapisují metadata. Když jsou metadata na 99,6 %, každý takový zápis tě dorazí. Řešení: mountovat s noatime (případně aspoň relatime zkontrolovat) na takovém objemu souborů.
4. Po smazání pár desítek GB to stále nešlo, dokud jsi neudělal balance ... -dusage=10.
To je správně – mazání uvolní místo logicky, ale ne vždy v chunku, který potřebuješ. Balance ti přerovnal data tak, že vznikl nealokovaný prostor → btrfs si pak mohl zvětšit metadata → vše se odblokovalo. Přesně tohle je ta „btrfs headroom“ vlastnost.
5. Proč to neudělá automaticky?
Tvoje očekávání je rozumné („když metadata dojdou, tak si udělej kousek místa sám“), ale btrfs to v tomhle rohu neumí bezpečně udělat samo – zvlášť u RAID6 profilů, které jsou i v roce 2025 pořád citlivější než RAID1/10. Raději abort transakce + RO, než aby sahal do všech datových BG a přerovnával bez tvého vědomí.
Co z toho plyne pro provoz:
• Nenechávat pole dojet na 100 % alokace. U tak velkého FS (8×14 TB, 40+ M souborů) klidně nechat 1–2 % zařízení nealokované.
• Cron balance, třeba:
btrfs balance start -musage=50 -dusage=5 /mnt/...
nebo i agresivněji podle chování.
• noatime na mountu.
• Monitoring btrfs fi usage a hlavně metadata – jakmile jsi nad ~95 %, řešit.
• Při mkfs si v zásadě nevynutíš “hodně metadat dopředu” v tom smyslu, jak bys chtěl; můžeš volit profil (--metadata raid6), ale to už máš. To, co ti fakt pomáhá, je mít nealokovaný kus + pravidelně balancovat.
Takže: není to, že by btrfs byl úplně „nekorektní“, ale jo – je to nepříjemný, málo zdokumentovaný roh btrfs, který u velkých, hodně souborových, RAID6 polí vyleze. Tvoje diagnóza „došla metadata a neměl si kam šáhnout pro nový chunk, dokud neproběhl balance“ je přesná.
Co se stalo:
1. Došly metadata, ne data.
Metadata, RAID6: total=134.62GiB, used=134.11GiB (99.63%) – tedy metadata plná. Když jsou metadata plná, btrfs přestane zapisovat a remountne se RO, i kdybys měl ještě stovky GB v Data. Proto zároveň vidíš:
space_info DATA has 131499511808 free, is full – to znamená „uvnitř datových block group je pár volných děr, ale já z nich teď nic neudělám“, ne že je disk fyzicky plný.
2. Btrfs si v tu chvíli už neumělo vytvořit nový metadatový chunk.
Aby si mohl přidat 1GB metadat v RAID6, musí mít nealokovaný prostor na zařízení. Ty jsi měl všechno alokované do datových chunků, takže nebylo kam ten nový metadatový chunk dát. Proto ti i balance na začátku spadl s No space left on device.
3. find ti zapisoval.
Říkáš „read-only úloha“, ale na btrfs (a u 42M souborů zvlášť) to není čisté čtení – aktualizuje se atime / relatime a tím se zapisují metadata. Když jsou metadata na 99,6 %, každý takový zápis tě dorazí. Řešení: mountovat s noatime (případně aspoň relatime zkontrolovat) na takovém objemu souborů.
4. Po smazání pár desítek GB to stále nešlo, dokud jsi neudělal balance ... -dusage=10.
To je správně – mazání uvolní místo logicky, ale ne vždy v chunku, který potřebuješ. Balance ti přerovnal data tak, že vznikl nealokovaný prostor → btrfs si pak mohl zvětšit metadata → vše se odblokovalo. Přesně tohle je ta „btrfs headroom“ vlastnost.
5. Proč to neudělá automaticky?
Tvoje očekávání je rozumné („když metadata dojdou, tak si udělej kousek místa sám“), ale btrfs to v tomhle rohu neumí bezpečně udělat samo – zvlášť u RAID6 profilů, které jsou i v roce 2025 pořád citlivější než RAID1/10. Raději abort transakce + RO, než aby sahal do všech datových BG a přerovnával bez tvého vědomí.
Co z toho plyne pro provoz:
• Nenechávat pole dojet na 100 % alokace. U tak velkého FS (8×14 TB, 40+ M souborů) klidně nechat 1–2 % zařízení nealokované.
• Cron balance, třeba:
btrfs balance start -musage=50 -dusage=5 /mnt/...
nebo i agresivněji podle chování.
• noatime na mountu.
• Monitoring btrfs fi usage a hlavně metadata – jakmile jsi nad ~95 %, řešit.
• Při mkfs si v zásadě nevynutíš “hodně metadat dopředu” v tom smyslu, jak bys chtěl; můžeš volit profil (--metadata raid6), ale to už máš. To, co ti fakt pomáhá, je mít nealokovaný kus + pravidelně balancovat.
Takže: není to, že by btrfs byl úplně „nekorektní“, ale jo – je to nepříjemný, málo zdokumentovaný roh btrfs, který u velkých, hodně souborových, RAID6 polí vyleze. Tvoje diagnóza „došla metadata a neměl si kam šáhnout pro nový chunk, dokud neproběhl balance“ je přesná.
