Re: [RFC PATCH] Revert "btrfs: allow mounting btrfs subvolumes with different ro/rw options"

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

Goffredo Baroncelli posted on Mon, 07 Jul 2014 19:37:53 +0200 as
excerpted:

> For "mounted RO" I mean the VFS flag, the "one" passed via the mount
> command. I say "one" as 1, because I am convinced that it has to act
> globally,
> e.g. on the whole filesystem; the flag should be set at the first mount,
> then it can be changed (only ?) issuing a "mount -o remount,rw/ro"
[...]
> So for each filesystem, there is a "globally" flag ro/rw which acts on
> the whole filesystem. Clear and simple.
> 
> Step 2: a more fine grained control of the subvolumes.
> We have already the capability to make a subvolume read-only/read-write
> doing
> 
>    # btrfs property set -t s /path/to/subvolume ro true
> 
> or
> 
>    # btrfs property set -t s /path/to/subvolume ro false
> 
> My idea is to use this flag. It could be done at the mount time for
> example:
> 
>   # mount -o subvolmode=ro,subvol=subvolname /dev/sda1 /
> 
> (this example doesn't work, it is only a my idea)
> 
> So:
> - we should not add further code
> - the semantic is simple
> - the property is linked to the subvolume in a understandable way
> 
> We should only add the subvolmode=ro option to the mount command.
> 
> Further discussion need to investigate the following cases:
> - if the filesystem is mounted as ro (mount -o ro....), does mounting a
> subvolume rw ( mount -o subvolmode=rw...) should raise an error ? 
> (IMHO yes)
> - if the filesystem is mounted as ro (mount -o ro....), does mounting
> the filesystem a 2nd time rw ( mount -o rw...) should raise an error ? 
> (IMHO yes)
> - if a subvolume is mounter rw (or ro), does mounting the same subvolume
> a 2nd time as ro (or rw) should raise an error ?
> (IMHO yes)

Makes sense.

Assuming I'm following you correctly, then, no subvolumes could be rw if 
the filesystem/vfs flag was set ro.

Which would mean that in ordered to mount any particular subvolume rw, 
the whole filesystem would have to be rw.

Extending now:

For simplicity and backward compatibility, if subvolmode isn't set, it 
corresponds to the whole-fs/vfs mode.  That way, setting mount -o ro,... 
(or -o rw,...) with the first mount would naturally propagate to all 
subsequent subvolume mounts, unless of course (1) all subvolumes and the 
filesystem itself are umounted, after which a new mount would be the 
first one again, or (2) a mount -o remount,... is done that changes the 
whole-fs mode.

Further, if it happened that one wanted the first subvolume mounted to be 
ro, but the filesystem as a whole rw so that other subvolumes could be 
mounted rw, the following would accomplish that:

mount -o rw,subvolmode=ro

That way, the subvol would be ro as desired, but the filesystem as a 
whole would be rw, so other subvolumes could be successfully mounted rw.

I like the concept. =:^)

The remaining problem to deal with is that if say the root subvol (id=5) 
is mounted rw,subvolmode=rw, while a subvolume below it is mounted 
subvolmode=ro, then what happens if someone tries to make an edit in the 
portion of the filesystem visible in the subvolume, but from the parent, 
id=5/root in this case?  Obviously if that modification is allowed from 
the parent, it'll change what's visible in the child subvolume as well, 
which would be rather unexpected.

I'd suggest that the snapshotting border rule should apply to writes as 
well.  Snapshots stop at subvolume borders, and writes should as well.  
Attempting to write in a child subvolume should error out -- child 
subvolumes are not part of a parent snapshot and shouldn't be writable 
from the parent subvolume, either.  Child-subvolume content should be 
read-only because it's beyond the subvolume border.

That would seem to be the safest.  Altho I believe it's a change from 
current behavior, where it's possible to write into any subvolume visible 
from the parent (that is, not covered by an over-mount, perhaps even of 
the same subvolume that would otherwise be visible in the same location 
from the parent subvolume), provided the parent is writable.

Regardless, my biggest take-away from the discussion so far is that I'm 
glad I decided to go with entirely separate filesystems, each on their 
own partitions, so my ro vs writable mounts do exactly what I expect them 
to do without me having to worry or think about it too much!  That wasn't 
the reason I did it -- I did it because I didn't want all my data eggs in 
the same whole-filesystem basket such that if a filesystem was damaged, 
the damage was compartmentalized -- but now that see all the subvolume rw/
ro implications discussed in this thread, I'm VERY glad I personally 
don't have to worry about it, and it all simply "just works" for me, 
because each filesystem is independent of the others, not simply a 
subvolume!

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