On 05/05/2023 09.21, Qu Wenruo wrote:
I would prefer a much simpler but more explicit method. Just introduce a new compat_ro feature, maybe call it SINGLE_DEV.
It is not clear to me if we need that. I don't understand in what checking for SINGLE_DEV is different from btrfs_super_block.disks_num == 1. Let me to argument: I see two scenarios: 1) mount two different fs with the same UUID NOT at the same time: This could be done now with small change in the kernel: - we need to NOT store the data of a filesystem when a disk is scanned IF it is composed by only one disk - after the unmount we need to discard the data too (checking again that the filesystem is composed by only one disk) No limit is needed to add/replace a disk. Of course after a disk is added a filesystem with the same UUID cannot be mounted without a full cycle of --forget. I have to point out that this problem would be easily solved in userspace if we switch from the current model where the disks are scanned asynchronously (udev which call btrfs dev scan) to a model where the disk are scanned at mount time by a mount.btrfs helper. A mount.btrfs helper, also could be a place to put some more clear error message like "we cannot mount this filesystem because one disk of a raid5 is missing, try passing -o degraded" or "we cannot mount this filesystem because we detect a brain split problem" .... 2) mount two different fs with the same UUID at the SAME time: This is a bit more complicated; we need to store a virtual UUID somewhere. However sometime we need to use the real fsid (during a write), and sometime we need to use the virtual_uuid (e.g. for /sys/fs/btrfs/<uuid>) Both in 1) and 2) we need to/it is enough to have btrfs_super_block.disks_num == 1 In the case 2) using a virtual_uuid mount option will prevent to add a disk. -- gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it> Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
