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... 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. >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
