Zygo Blaxell wrote:

quoted

quoted

commit
space_cache / nospace_cache
sdd / ssd_spread / nossd / no_ssdspread

How could those be anything other than filesystem-wide options?

Well being me, I tend to live in a fantasy world where BTRFS have 
complete world domination and has become the VFS layer.
As I have nagged about before on this list - I really think that the 
only sensible way forward for BTRFS (or dare I say BTRFS2) would be to 
make it possible to assign "storage device groups" where you can make 
certain btrfs device ids belong to group a,b,c, etc...

And with that it would be possible to assign a weight to subvolumes so 
that they would be preferred to be stored on group a (SSD's perhaps), 
while other subvolumes would be stored mostly or exlusively on HDD's, 
Fast HDD's, Archival HDD's etc... So maybe a bit over enthusiastic in 
thinking perhaps , but hopefully you see now why I think it is right 
that this is not filesystem-wide , but subvolume baseed properties.

quoted

quoted

discard / nodiscard

Maybe, but probably requires too much introspection in a fast path (we'd
have to add a check for the last owner of a deleted extent to see if it
had 'discard' set on some parent level).

On the other hand, I'm in favor of deprecating the whole discard option
and going with fstrim instead.  discard in its current form tends to
increase write wear rather than decrease it, especially on metadata-heavy
workloads.  discard is roughly equivalent to running fstrim thousands
of times a day, which is clearly bad for many (most?  all?) SSDs.

It might be possible to make the discard mount option's behavior more
sane (e.g. discard only full chunks, configurable minimum discard length,
discard only within data chunks, discard only once per hour, etc).

Interesting, it might as well make sense to perhaps use the free space 
cache and a slow LRU mechanism e.g. "these chunks has not been in use 
for 64 hours/days" or something similar.

quoted

quoted

compress / compress-force
datacow / nodatacow
datasum / nodatasum

Here's where I prefer the mount option over the more local attributes,
because I'd like filesystem-level sysadmin overrides for those.
i.e. disallow all users, even privileged ones, from being able to create
files that don't have csums or compression on a filesystem.

Then how about a mount option that allow only root to do certain things? 
e.g. a security restriction.

quoted

quoted

user_subvol_rm_allowed

I'd like "user_subvol_create_disallowed" too.  Unprivileged users can
create subvols, and that breaks backups that rely on atomic btrfs
snapshots.  It could be a feature (it allows users to exclude parts of
their home directory from backups) but most users I've met who have
discovered this "feature" the hard way didn't enjoy it.

Historically I had other reasons to disallow subvol creates by
unprivileged users, but they are mostly removed in 4.18, now that 'rmdir'
works on an empty subvol.

Again see above...