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.
Thanks, Anand
fs/btrfs/volumes.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index b408a3f7229e..7da65625677f 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1035,8 +1035,7 @@ static int __btrfs_open_devices(struct btrfs_fs_devices *fs_devices,
list_for_each_entry(device, head, dev_list) {
/* Just open everything we can; ignore failures here */
- ret = btrfs_open_one_device(fs_devices, device, flags, holder);
- if (ret)
+ if (btrfs_open_one_device(fs_devices, device, flags, holder))
continue;
if (!latest_dev ||
--
2.15.0
--
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
