[...]

quoted

That's possible (and there are patches attempting to address it).
We don't want to be too aggressive, or the disk fills up with unused
metadata allocations...but we need to be about 5 block groups more
aggressive than we are now to handle special cases like "mount and
write until full without doing any backups or maintenance."

Wouldn't a "simple" (at least in my mind ;-) ) solution be, that:
- if the case arises, that either data or meta-data block groups are
   full
- and not unallocated space is left
- and if the other kind of block groups has plenty of free space left
   (say in total something like > 10 times the size of a block group...
   or maybe more (depending on the total filesystem size), cause one
   probably doesn't want to shuffle loads of data around, just for the
   last 0.005% to be squeezed out.)
then:
- btrfs automatically does the balance?
   Or maybe something "better" that also works when it would need to
   break up extents?

Or, let's change how we output our vanilla `df` command output, by
taking metadata free space and unallocated space into consideration, like:

- If there are plenty unallocated space
   Go current output.

- If there is no more unallocated space can be utilized
   Then take metadata free space into consideration, like if there is
   only 1G free metadata space, while several tera free data space,
   we only report free metadata space * some ratio as free data space.

   And if by some magic calculation, we determined that even balance
   won't free up any space, we return available space as 0 directly.

By this, we under-report the amount of available space, although users
may (and for most cases, they indeed can) write way more space than the
reported available space, we have done our best to show end users that
they need to take care of the fs.
Either by deleting unused data, or do proper maintenance before reported
available space reaches 0.

By this, your existing space reservation tool will work way better than
your current situation, and you have enough early warning before
reaching the current situation.

But I doubt if this would greatly drop the disk utilization, as we will
become too cautious on reporting available space.

Thanks,
Qu

If there are cases where one doesn't like that automatic shuffling, one
could make it opt-in via some mount option.

quoted

A couple more suggestions (more like exploitable side-effects):

         - Run regular scrubs.  If a write occurs to a block group
         while it's being scrubbed, there's an extra metadata block
         group allocation.

But writes during scrubs would only happen when it finds and corrupted
blocks?


Thanks,
Chris.