Re: Should seed device be allowed to be mounted multiple times?

[Qu Wenruo <wqu@suse.com>]

在 2025/8/5 22:13, Christian Brauner 写道:
> On Tue, Aug 05, 2025 at 10:22:49AM +0930, Qu Wenruo wrote:
>>
>>
>> 在 2025/8/5 10:06, Anand Jain 写道:
>>>
>>>
>>>>> Thanks for the comments.
>>>>> Our seed block device use-case doesn’t fall under the kind of risk that
>>>>> BLK_OPEN_RESTRICT_WRITES is meant to guard against—it’s not a typical
>>>>> multi-FS RW setup. Seed devices are readonly, so it might be reasonable
>>>>> to handle this at the block layer—or maybe it’s not feasible.
>>>
>>>
>>>> Read-only doesn't prevent the device from being removed suddenly.
>>>
>>> I don't see how this is related to the BLK_OPEN_RESTRICT_WRITES flag.
>>> Can you clarify?
>>
>> It's not related to that flag, I'm talking about the fs_bdev_mark_dead(),
>> and the remaining 3 callbacks.
>>
>> Those call backs are all depending on the bdev holder to grab a super block.
>>
>> Thus a block device should and can not have multiple super blocks.
> 
> I'm pretty sure you can't just break the seed device sharing use-case
> without causing a lot of regressions...

It's not that widely affecting, we can still share the same seed device 
for all different sprout fses, just only one of them can be mounted at 
the same time.

And even with that limitation, it won't affect most (or any) real world 
use cases.

Even the most complex case like using seed devices as rootfs, and we 
want to sprout the rootfs again, just remove the seed device from the 
current rootfs, then one can mount the seed device again.

> 
> If you know what the seed devices are than you can change the code to
> simply use the btrfs filesystem type as the holder without any holder
> operations but just for seed devices. Then seed devices can be opened
> by/shared with any btrfs filesystem.

But we will lose all the bdev related events.

We still want to sync/freeze/thaw the real sprouted fs in the end.

> 
> The only restriction is that you cannot use a device as a seed device
> that another btrfs filesystem uses as a non-seed device because then it
> will be fully owned by the other btrfs filesystem. But Josef tells me
> you can only use it as a seed device anyway.
> 
> IOW, if you have a concept of shareable devices between different btrfs
> filesystems then it's fine to reflect that in the code. If really needed
> you can later add custom block holder ops for seed devices so you can
> e.g., iterate through all filesystems that share the device.

Sure it's possible, with a lot of extra code looking up where the seed 
device belongs, and all the extra bdev event proxy.


But I'd say, the seed device specification is not well specified in the 
very beginning, thus it results a lot of "creative" but not practical 
use cases.

Yes, this will result some regression, but I'd prefer a more sounding 
and simpler logic for the whole seed device, with minimal impact to the 
most common existing use cases.

Thanks,
Qu