Re: feature request: consider rw subvols ro for send when volume is mounted ro

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

Zach Brown posted on Wed, 23 Jul 2014 13:47:36 -0700 as excerpted:

> On Wed, Jul 23, 2014 at 02:10:29PM -0600, Chris Murphy wrote:
>> The use case is when it's possible to mount a Btrfs volume ro, but not
>> rw. Example, a situation where
>> 
>> # mount -o degraded /dev/sdb /mnt
>> [...] BTRFS: too many missing devices, writeable mount is not allowed 
>> 
>> Yet this works:
>> # mount -o degraded,ro /dev/sdb /mnt
>> 
>> It would be great if it were possible to send/receive subvolumes to a
>> different btrfs volume. Currently it's not possible because those
>> subvols aren't ro, and because the mount is ro I can't make ro
>> snapshots first.

In general, btrfs send/receive is great when it works, but because 
there's still corner-cases like this as well as simply broken send/
receive cases popping up from time to time, I strongly recommend not 
relying on it working, and keeping a more conventional backup option 
(like rsync) tested-working and usable as well.
 
> I wonder if that's as easy as the following totally untested hack.  I
> have no idea if a read-only mount would still allow background
> modification that might violate the send code's assumptions.

Hopefully that hack works.

Meanwhile, AFAIK, yes, there's still cases where a read-only mount can 
still allow background mods that would violate send's assumptions.  Tho I 
don't believe they apply in this case.  But certainly, there has been 
recent discussion on the subvolume mount situation, since it's possible 
to access child subvolumes from writable-mount parent (including root/
id5) subvolumes, and currently nothing stops writing into the read-only-
child's mount from the parent's writable mount.

Even without that situation, however, there's bind-mounts, which start 
out with the same mount options as the original, but with a remount allow 
one of the views to be read-only while the other is writable, regardless 
of the filesystem.  Obviously that allows changing the view on the read-
only side from the writable side.

So while having the ability to do a send from a read-only mount is indeed 
a good thing to have in emergency cases such as this, I'd suggest 
requiring a --force option or the like to enable it, since the full 
immutable-read-only guarantees simply aren't there.

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