Re: Is it safe to mount subvolumes of already-mounted volumes (even with different options)?

[Duncan <1i5t5.duncan@cox.net>]

Hugo Mills posted on Thu, 17 Jul 2014 09:41:53 +0100 as excerpted:

>> and are there any combinations of possibly conflicting mount options
>> one should be aware of (compression, autodefrag, cache clearing)? Is it
>> advisable to use the same mount options for all mounts pointing to the
>> same physical device?
> 
>    If you assume that the first mount options are the ones used for
> everything, regardless of any different options provided in subsequent
> mounts, then you probably won't go far wrong. It's not quite true: some
> options do work on a per-mount basis, but most are per-filesystem. I'm
> sure there was a list of them on the wiki at some point, but I can't
> seem to track it down right now.

IIRC/AFAIK, the btrfs-specific mount options should be per filesystem, 
while stuff like relatime vs noatime is VFS level and should work per 
subvolume.

There's actually a current discussion about ro vs rw.  Consider the case 
of a parent subvolume (perhaps but not necessarily the root subvolume, 
id=5), being mounted writable in one location, with a child mounted 
elsewhere read-only.  Because it's possible to browse in the parent's 
subvolume down into the child subvolume as well, and someone could write 
a file there, that write would then show up in the elsewhere mounted read-
only child subvolume as well.

That's unexpected behavior to say the least!  Normally, read-only means 
it cannot and will not change, but in this case it wouldn't mean that at 
all!

My idea is that the same rules should apply to ro/rw as apply to btrfs 
snapshots -- they stop at subvolume borders.  Any write into a child 
subvolume would thus throw an error, regardless of how the parent 
subvolume was mounted.  The only way to write into a subvolume would be 
to mount it read-write on its own.  That would solve the ambiguity, but 
it would also be quite a change from existing behavior, where a read-
write mount of the root subvolume can write into any subvolume.

Someone else suggested that we separate filesystem read-write from 
subvolume read-write.  There's already the concept of read-only 
snapshots, used in btrfs-send, for one thing.  The idea here would be 
that a read-only filesystem/root mount means the entire filesystem is 
read-only, but provided the filesystem/root was mounted read-write, 
individual subvolumes could be mounted read-only using a different 
option, subv=ro, or similar, which would be hooked into the existing read-
only subvolume mechanism.  In that case, if the filesystem/root was read-
write, then the subvolume specific rw/ro mount option would take 
precedence and would trigger an error on write to that subvolume even if 
written from the read-write parent mount.

But while btrfs is the first filesystem to do this sort of thing and thus 
to deal with the problem, it might not be the last, so policy 
coordination with the VFS layer should be considered and a generic kernel 
policy for any filesystem dealing with subvolumes should be established.  
IOW, it's bigger than simply btrfs.

So anyway, while there was a patch applied earlier that did allow 
different read-only/read-write subvolume mounts, I believe that's 
reverted for 3.16, while this discussion continues and until it gets 
resolved one way or another, possibly at a kernel conference or the like.

But I believe generic VFS stuff like noatime/relatime/atime and dev/nodev/
suid/nosuid/exec/noexec is fine per-subvolume, because that's enforced at 
the VFS layer and there's no internal or expectation inconsistency to 
worry about if you can access for example the same device-file as a 
device via one mountpoint and not by another.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman