On 4.10.19 г. 12:08 ч., Graham Cobb wrote: > On 04/10/2019 09:11, Nikolay Borisov wrote: >> >> >> On 4.10.19 г. 10:50 ч., Anand Jain wrote: >>> btrfs_free_extra_devids() reorgs fs_devices::latest_bdev >>> to point to the bdev with greatest device::generation number. >>> For a typical-missing device the generation number is zero so >>> fs_devices::latest_bdev will never point to it. >>> >>> But if the missing device is due to alienating [1], then >>> device::generation is not-zero and if it is >= to rest of >>> device::generation in the list, then fs_devices::latest_bdev >>> ends up pointing to the missing device and reports the error >>> like this [2] >>> >>> [1] >>> mkfs.btrfs -fq /dev/sdd && mount /dev/sdd /btrfs >>> mkfs.btrfs -fq -draid1 -mraid1 /dev/sdb /dev/sdc >>> sleep 3 # avoid racing with udev's useless scans if needed >>> btrfs dev add -f /dev/sdb /btrfs >> >> Hm, here I think the correct way is to refuse adding /dev/sdb to an >> existing fs if it's detected to be part of a different one. I.e it >> should require wipefs to be done. > > I disagree. -f means "force overwrite of existing filesystem on the > given disk(s)". It shouldn't be any different whether the existing fs is > btrfs or something else. You are right, looking at btrfs device add implementation though it seems that wipefs is being done on the device to be added: cmd_device_add btrfs_prepare_device btrfs_wipe_existing_sb So if the device to be added is formatted and then it goes through btrfs_init_new_device which commits the transaction which in turns rewrites the sb then why is the error happening in the first place? > > Graham >
