On 05/05/2023 19:15, Qu Wenruo wrote: > [...] >> 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. Awesome, thanks for clarifying Qu! Now I understand it =) > [...] >> 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. OK, I understand your point. I guess I could rewrite it to make use of such compat_ro flag, it'd be fine. *Personally* (thinking as an user), I much rather have mount options, I think it's consistent with other filesystems and doesn't require specific btrfs tooling usage... But of course I'll defer the decision to the maintainers! Cheers, Guilherme
