Re: Seed device is broken, again.

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/3/2 01:09, David Sterba wrote:
> On Tue, Mar 01, 2022 at 08:13:28AM +0800, Qu Wenruo wrote:
>>
>>>
>>> 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.
>>
>> My main concern is still there, we change RO to RW without any remount.
>
> We also do emergency remount from RO to RW, so I take it as that
> changing the status is partiall in the hands of filesystem, not
> violating APIs and such.
>
>> It's weird from the beginning, but we just accept that.
>>
>> If we have chance to rethink this, would we still take the same path?
>> Other than making seed device into user space tool like mkfs?
>
> I'm not sure it would work the same way as now, the seeding device can
> be mounted several times in parallel as the UUID is generated at each
> mount, then added the writeable device, then thrown away. Any detour
> through userspace make it more complicated, but I haven't thought that
> through. We could add it no top of the on-line seeding as another
> usecase but if current users are fine with how it works now I don't
> think we need to spend time on implementing it.

Then let me try that.

At least to me, using seed device to create a new RW fs really looks
like a perfect match to mkfs.btrfs.

We already have things like mkfs.btrfs -R to populate the fs.
Using seed device would be more suitable to me.

Thanks,
Qu