On 30/4/20 9:46 pm, David Sterba wrote:
On Tue, Apr 28, 2020 at 11:22:26PM +0800, 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 alienation [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] We maintain devices of a fsid (as in fs_device::fsid) in the
fs_devices::devices list, a device is considered as an alien device
if its fsid does not match with the fs_device::fsid
$ mkfs.btrfs -fq /dev/sdd && mount /dev/sdd /btrfs
Please put each command on one line for clarity
yep.
$ 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
$ mount -o degraded /dev/sdc /btrfs1
So the cause is a second mkfs on some devices, but is the degraded mount
supposed to work? The example goes:
Yes. It must work. We don't know if the user is mounting B just after
mkfs or if it already contains some data.
- create first filesystem with device A
- create second filesystem with device B and C
- add device B to the first filesystem, effectively making it missing
- mount first filesystem, degraded because of the missing device
For a reproducer that's ok, but is this something that we can expect to
happen in practice? The flag -f should prevent accidental overwrite, but
yes the kernel code needs to deal with that in any case.
Its a configuration related, so is left the user how they arrive at
their understanding of what configuration is suitable for them. Yes its
better to fix loop holes in its path. I encountered it when testing
something else.
