Re: Why do we need these mount options?

[waxhead <waxhead@dirtcellar.net>]

Zygo Blaxell wrote:
> 
>>> 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.

>>> 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.

>>> 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.

> 
>>> 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...