On Fri, Dec 01, 2017 at 07:02:30AM +0800, Anand Jain wrote: > Test case like btrfs-progs test-misc/012 can recreate the same fsid with > different number of struct btrfs_fs_devices::total_devices. And the > previous device which is in the kernel device list is stale now, but as > we don't clean the kernel device list, and in the mount context, it really > ends up reading the device to find its zeroed SB. And thus return the fail > to mount. > > The long term fix for this should be to create a new kernel device list, > for the mount context. > > Though the patch > btrfs: factor __btrfs_open_devices() to create btrfs_open_one_device() > did tried to skip the failed open, but it forgot to reset the ret value. > Thus returning the error up the stack in the mount context. > > Signed-off-by: Anand Jain <anand.jain@xxxxxxxxxx> > Fixes: > btrfs: factor __btrfs_open_devices() to create btrfs_open_one_device() > --- > Hi David, > > My bad. The above patch introduced a regression. Can you kindly squash > this patch to it. Done. Thank you both. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
