On 30.04.20 г. 20:54 ч., Anand Jain wrote: > > > On 30/4/20 2:05 pm, Nikolay Borisov wrote: >> >> >> On 28.04.20 г. 18:22 ч., Anand Jain wrote: >>> v3 REBASED: Based on the latest misc-next. for for-5.8. >>> Dropped the following patches as there were concerns about the usage >>> of error code -EUCLEAN >>> btrfs: remove identified alien device in open_fs_devices >>> btrfs: remove identified alien btrfs device in open_fs_devices >>> >>> Rmaining 3 patches here have obtained reviewed-by. With this pathset >>> the pertaining fstests btrfs/197 and btrfs/198 (which tests 3 bugs) >>> would pass as the patch 2/3 fixed a bug and 3/3 fixed the trigger >>> of 2 other bugs (patch 1/3 is just a cleanup). Further at the moment >>> I am not sure if there is any other trigger where it could again >>> leave >>> an alien device in the fs_devices leading to the same/similar bugs. >>> >>> ==== original email ==== >>> v3: Fix alien device is due to wipefs in Patch4. >>> Fix a nit in Patch3. >>> Patches are reordered. >>> >>> Alien device is a device in fs_devices list having a different fsid than >>> the expected fsid or no btrfs_magic. This patch set fixes issues >>> found due >>> to the same. >>> >>> Patch1: is a cleanup patch, not related. >>> Patch2: fixes failing to mount a degraded RAIDs (RAID1/5/6/10), by >>> hardening the function btrfs_free_extra_devids(). >>> Patch3: fixes the missing device (due to alien btrfs-device) not >>> missing in >>> the userland, by hardening the function btrfs_open_one_device(). >>> Patch4: fixes the missing device (due to alien device) not missing in >>> the userland, by returning EUCLEAN in btrfs_read_dev_one_super(). >>> Patch5: eliminates the source of the alien device in the fs_devices. >>> >>> PS: Fundamentally its wrong approach that btrfs-progs deduces the device >>> missing state in the userland instead of obtaining it from the kernel. >>> I remember objecting on the btrfs-progs patch which did that, but still >>> it got merged, bugs in p3 and p4 are its side effects. I wrote >>> patches to read device_state from the kernel using ioctl, procfs and >>> sysfs but it didn't get the due attention till a merger. >>> >>> Anand Jain (3): >>> btrfs: drop useless goto in open_fs_devices >>> btrfs: include non-missing as a qualifier for the latest_bdev >>> btrfs: free alien device due to device add >>> >>> fs/btrfs/volumes.c | 30 ++++++++++++++++++++++-------- >>> 1 file changed, 22 insertions(+), 8 deletions(-) >>> >> >> >> One thing I'm not clear is how can we get into a situation of an alien >> device. I.e devices should be in fs_devices iff they are part of the> >> filesystem, no ? >> > > I think you are missing the point that, when the devices (of a > raid1/raid5/raid6) are unmounted, we don't free any of their > fs_devices::device. So in this situation if one of those devices is > added to any another fsid (using btrfs device add) or wiped using wipefs > -a, we still don't free the device's former fs_devices::device entry in > the kernel and it acts as an alien device among its former partners when > it is mounting. So it could happen only due to a deliberate action by the user and not during normal operation. In this case is it not the user's responsibility to remove/forget the device from that file system?
