On 2023/5/5 23:51, Guilherme G. Piccoli wrote:
On 05/05/2023 04:21, Qu Wenruo wrote:
[...]
Exactly, the biggest problem is the multi-device support.
Btrfs needs to search and assemble all devices of a multi-device
filesystem, which is normally handled by things like LVM/DMraid, thus
other traditional fses won't need to bother that.
Hi Qu, thanks a bunch for your feedback, and for validating my
understanding of the issue!
[...]
I would prefer a much simpler but more explicit method.
Just introduce a new compat_ro feature, maybe call it SINGLE_DEV.
By this, we can avoid multiple meanings of the same super member, nor
need any special mount option.
Remember, mount option is never a good way to enable/disable a new feature.
The better method to enable/disable a feature should be mkfs and btrfstune.
Then go mostly the same of your patch, but maybe with something extra:
- Disbale multi-dev code
Include device add/replace/removal, this is already done in your
patch.
- Completely skip device scanning
I see no reason to keep btrfs with SINGLE_DEV feature to be added to
the device list at all.
It only needs to be scanned at mount time, and never be kept in the
in-memory device list.
This seems very interesting, but I'm a bit confused on how that would
work with 2 identical filesystem images mounted at the same time.
Imagine you have 2 devices, /dev/sda1 and /dev/sda2 holding the exact
same image, with the SINGLE_DEV feature set. They are identical, and
IIUC no matter if we skip scanning or disable any multi-device approach,
in the end both have the *same* fsid. How do we track this in the btrfs
code now? Once we try to mount the second one, it'll try to add the same
entity to the fs_uuids list...
My bad, I forgot to mention that, if we hit such SINGLE_DEV fses, we
should also not add them to the fs_uuids list either.
So the fs_uuids list conflicts would not be a problem at all.
That's the problem I faced when investigating the code and why the
proposal is to "spoof" the fsid with some random generated one.
Also, one more question: why do you say "Remember, mount option is never
a good way to enable/disable a new feature"? I'm not expert in
filesystems (by far heh), so I'm curious to fully understand your
point-of-view.
We had a bad example in the past, free space tree (aka, v2 space cache).
It's initially a pretty convenient way to enable the new feature, but
now it's making a lot of new features, which can depend on v2 cache,
more complex to handle those old mount options.
The compatibility matrix would only grow, and all the (mostly one-time)
logic need to be implemented in kernel.
So in the long run, we prefer offline convert tool.
Thanks,
Qu
From my naive viewpoint, seems a mount option is "cheaper" than
introducing a new feature in the OS that requires changes on btrfs
userspace applications as well as to track incompatibilities in
different kernel versions.
Thanks again,
Guilherme
