Double Commander and PCManFM-QT are showing 512 MB free space , but when trying save a simple text file of 10 KB happen a high disk activity for some seconds and then a error message about not being possible save the file because the disk not have enough free space. Not is possible manually copy files to that partition too with the same error message.
I have used other file system in all my years using computer being the first time seeing a file system with that restriction or error.
BTRFS is a serious problem when happen damage in file system. You need much luck to not happen the terrible parent transid error being an fatal error. I miss the number of times seeing that happening and not any fix was done in that strange file system. About the features is really very good, but when happen problem is one of more terrible file system.
I continue using because file compression in HDD.
Have any action to do for allow use all free space in BTRFS partitions ?
Have a nice week.
To understand what’s happening, you should first show the actual Btrfs space allocation: sudo btrfs filesystem usage -T /
and sudo btrfs filesystem df /
Without those outputs it’s difficult to determine whether the reported free space is a real filesystem issue or just a reporting problem.
Also, I hope you’re aware of the filesystem features you enabled during mkfs. Changing the checksum algorithm is generally fine, but some of the other options deserve consideration:
-M / mixed-bg: stores data and metadata in the same block groups. This is usually intended for small filesystems and is generally not recommended on large filesystems.
skinny-metadata: default since btrfs-progs 3.18, kernel support since 3.10.
no-holes: default since btrfs-progs 5.15, kernel support since 3.14.
block-group-tree: default since btrfs-progs 6.19, kernel support since 6.1.
Regarding:
Double Commander and PCManFM-Qt are showing 512 MB free space
This looks more like a file manager reporting issue than a Btrfs bug. In many cases the problem is that file managers are not fully aware of how Btrfs compression affects space usage and available-space calculations.
Regarding:
BTRFS is a serious problem when happen damage in file system. You need much luck to not happen the terrible parent transid error being an fatal error.
A “parent transid verify failed” error is not typically caused by normal Btrfs operation. One of the most common causes is storage firmware or hardware that does not correctly honor write ordering or FLUSH/FUA requests, resulting in writes reaching the device in a different order than expected. This is a well-known cause of parent transid errors.
About the features is really very good, but when happen problem is one of more terrible file system.
Btrfs is the default filesystem in distributions such as openSUSE, Fedora Linux and its derivatives such as Ublue, SteamOS(rootFS), CachyOS and Manjaro, and is also widely used by several NAS vendors. If parent transid errors were a common occurrence during normal operation, Btrfs would not be deployed so widely as a default filesystem across millions of systems.
While this is true one should note that btrfs is not supported at all in Ubuntu.
That means there is no particular testing on a kernel level (unlike for any supported ones that receive automated tests for every kernel build) and all userspace tools come as-is untouched from the Debian archive and live in the universe part of the archive.
So to make sure to not be vulnerable to any CVEs it is essential to enable Ubuntu Pro to get any security fixes for these userspace tools…
Just because it says there is free space, doesn’t mean you get to use it; it’s a known issue and no easy way of predicting when exactly one hits ENOSPC.
That will show how much is actually still available in the “Unallocated” column. It’s also a good idea to reserve some slack space for whenENOSPC happens; found that hint somewhere of superuser or serverfault.
I was under the impression that, as a longer term goal, it will be supported eventually. I even followed some HowTo which had the recommended/envisioned subvolume layout (@ for /, @home for /home etc.; essentially an @ where a / will be in the target mount path). The gist of it was something like “if you want to take a sneak peek at the future of Ubuntu’s BTRFS support, do …” I don’t quite remember where I had found that guide, though; it looked like it was written by someone (or someone who knew someone) in the know.
Only just yesterday I ran the Ubuntu 26.04 Desktop installer and it let me select BTRFS as filesystem in the manual partitioning step.
It only offers Ext4, XFS, Btrfs and VFAT, so it must be a curated list of what Canonical is prepared to support, perhaps on a “tech preview” basis — I think that was the term I heard sometime around 2020; much like ZFS back when that was announced. I didn’t click “Next” yesterday, because I was actually trying to do something else, but I did click it just now, just to see what I get when it’s done.
Recent Btrfs developments have specifically targeted ENOSPC situations caused by fragmented free space and reclaim limitations. Features such as dynamic_reclaim and periodic_reclaim were introduced to improve automatic space reclamation and reduce cases where the filesystem reports free space but cannot immediately allocate it. Meta is using these improvements successfully in production [1], and there is interest in enabling them by default in the future.
[1] We have tested it extensively in production at Meta and are quite
satisfied with its behavior as opposed to an edge triggered
bg_reclaim_threshold set to 25. The latter did well in reducing our
ENOSPCs but at the cost of a LOT of reclaiming. And often excessive
seemingly unbounded reclaiming.
If additional capacity is needed, a user can add it by attaching another partition or block device with sudo btrfs device add, rebalance or free space as needed, and then remove the device again, all while the filesystem remains mounted and operational.
I’ve reserved slack space just for that purpose; from past experience, 1GiB seems to be enough to get a badly unbalanced BTRFS rebalanced. It’s a bit akin to the 5% reserve for root on ext2, IIRC. Just shrinking the filesystem by the desired amount turns the now unallocatable space into “Device slack”, as shown by sudo btrfs filesystem usage. I have two separate BTRFS pools on different hardware — one is 500 GB and the other is 1 TB — and have reserved 0.2%, i.e. 2GB for the 1TB device, for slack. I cannot find the actual source of that tip, so credit and a huge “Thank you!” goes to some unknown hacker on serverfault.com or superuser.com, I think is where I saw it. Now I don’t have ENOSPC anxiety anymore.
Thank you very much for the news, BTW!
Doesn’t mean it’s an easy fix. To me it looks like it comes with the territory of CoW; the best we can hope for is a more graceful way to deal with it, I reckon. It’s about mitigating rather than fixing it. But I’m no expert by any stretch of the imagination.
Btrfs may be stable upstream, but distro support matters too. Ubuntu users should be aware that it doesn’t get the same level of testing and support as the default filesystems, so keeping tools updated and checking security coverage is important for production use.
No, they don’t. No high level tool like that should need to know implementation details of the filesystem; that’s the whole point of such abstraction layers. It’s also probably not the global reserve; that one could well be hidden to the outside world by BTRFS, but I don’t know if it is. How do you know it isn’t? Share your sources. You seem to be fairly new to the BTRFS game and to still be finding your feet. As I’ve tried to explain earlier, you can run out of space with more than 10 GB “free” space, depending on the size of the whole pool. It just comes with the territory.
If you want to have a real conversation about it, you should stop being so tight-lipped. Explain and show what you’re on about and provide info (links, screenshot, log excerpts) so the forum can follow.
I agree that more details are needed before drawing conclusions. Btrfs has its own way of managing space, including metadata and allocation behavior, so a simple “free space” figure may not tell the whole story. Sharing the exact commands, filesystem layout, and any relevant logs or screenshots would help everyone understand what’s actually happening and provide a more accurate answer.
