Re: Seed device is broken, again.

[David Sterba <dsterba@suse.cz>]

On Mon, Feb 28, 2022 at 11:27:16AM +0800, Qu Wenruo wrote:
> > Ah. That's fine, IMO. It is a matter of understanding the nature of the
> > seed device. No?
> > The RO mount used to turn into an RW mount after the device-add a long
> > ago. It got changed without a trace.
> 
> Think twice about this, have you every seen another fs allowing a RO
> mount to be converted to RW without even remounting?

There's no other filesystem with a remotely close feature so we can't
follow an established pattern.

The ro->rw transition can be done from inside the filesystem too and
btrfs sort of does that in btrfs_mount, calling kern_mount.

> Still think this doesn't provide any surprise to end users?

The RO status means the filesystem does not support any write operations
from the user perspective that go through VFS. Adding the device in the
seed mode modifies the filesystem structures, ie. changes the block
device, but does not change the VFS status regarding writability.  The
read-write remount is mandatory to actually make use of the writable
device. This is documented and I don't find it confusing from the end
user perspective.

If you're concerned that there's a write to the block device then yes,
it's a bug that the mnt_set_write should be done just before we start
any change operation.

There was a discussion some time ago if the log replay should happen on
a read-only mount, or any potential repair action that could happen
regardless of the ro/rw mount status. The conclusion was that it could
happen, and guaranteeing no writes to the block device should be done
externally eg. by blockdev --setro. But I think we opted not to do any
writes anyway for btrfs.