As we speak, btrfs is broken by design in this regard.
There is currently no function in btrfs-progs, to show which subvolume has which quota. You have to write a script (and many who fell for btrfs do), to parse the abstract quota group numbers it outputs, and list the subvolumes inside those quota groups below them.
It could be added, but the btrfs developers religiously refuse to do this.
Even worse, there is not only no way to show how much of the quota a subvolume currently uses up. Which is why df
only shows the total free space.
It is not possible to do this at all due to how btrfs is designed at its very core. This is because subvolumes work like snapshots. Meaning, to find out how much data is in a subvolume, you’d have to scan the entire file system, and find all the files linked to that subvolume/snapshot, and add them up. Just like the du
command. Which takes a lot of time.
I have no idea how btrfs then knows a quota is full at all… The IRC channel could not provide me with any answer to that. (They were to busy defending their fragile over-inflated egos.)
The sensible thing would be, to change the subvolume counter each time data is added or removed. Which kinda must be how btrfs knows it is full. At least I don’t know any other way. But why they would then chose to keep this available info basically a military-guarded state secret, I don’t know…
If zfs wouldn’t have such insane RAM requirements (1GB per TB … not an option on e.g. a single-board ARM computer) and the risk of data loss, due to not writing data early, due to being designed for servers with crash protection, I would recommend dumping btrfs in its favor.