diff mbox series

btrfs: free device in btrfs_close_devices for a single device filesystem

Message ID faf1de6f88707dbf0406ab85e094e72107b30637.1674221591.git.anand.jain@oracle.com (mailing list archive)
State New, archived
Headers show
Series btrfs: free device in btrfs_close_devices for a single device filesystem | expand

Commit Message

Anand Jain Jan. 20, 2023, 1:47 p.m. UTC
We have this check to make sure we don't accidentally add older devices
that may have disappeared and re-appeared with an older generation from
being added to an fs_devices (such as a replace source device). This
makes sense, we don't want stale disks in our file system. However for
single disks this doesn't really make sense. I've seen this in testing,
but I was provided a reproducer from a project that builds btrfs images
on loopback devices. The loopback device gets cached with the new
generation, and then if it is re-used to generate a new file system we'll
fail to mount it because the new fs is "older" than what we have in cache.

Fix this by freeing the cache when closing the device for a single device
filesystem. This will ensure that the mount command passed device path is
scanned successfully during the next mount.

Reported-by: Daan De Meyer <daandemeyer@fb.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
---
Retained the original bug description as in the patch [1].
This patch is a revised fix for the fstests test case btrfs/219

   [1] btrfs: allow single disk devices to mount with older generations

 fs/btrfs/volumes.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

Comments

Josef Bacik Jan. 30, 2023, 7:34 p.m. UTC | #1
On Fri, Jan 20, 2023 at 09:47:16PM +0800, Anand Jain wrote:
> We have this check to make sure we don't accidentally add older devices
> that may have disappeared and re-appeared with an older generation from
> being added to an fs_devices (such as a replace source device). This
> makes sense, we don't want stale disks in our file system. However for
> single disks this doesn't really make sense. I've seen this in testing,
> but I was provided a reproducer from a project that builds btrfs images
> on loopback devices. The loopback device gets cached with the new
> generation, and then if it is re-used to generate a new file system we'll
> fail to mount it because the new fs is "older" than what we have in cache.
> 
> Fix this by freeing the cache when closing the device for a single device
> filesystem. This will ensure that the mount command passed device path is
> scanned successfully during the next mount.
> 

Dave, I think I like this approach better actually, it may be less error prone
than my fix, if we just delete single disks from the device cache we can remount
whatever later.  This may be safer than what I suggested, what do you think?

Josef
David Sterba Feb. 7, 2023, 4:04 p.m. UTC | #2
On Mon, Jan 30, 2023 at 02:34:57PM -0500, Josef Bacik wrote:
> On Fri, Jan 20, 2023 at 09:47:16PM +0800, Anand Jain wrote:
> > We have this check to make sure we don't accidentally add older devices
> > that may have disappeared and re-appeared with an older generation from
> > being added to an fs_devices (such as a replace source device). This
> > makes sense, we don't want stale disks in our file system. However for
> > single disks this doesn't really make sense. I've seen this in testing,
> > but I was provided a reproducer from a project that builds btrfs images
> > on loopback devices. The loopback device gets cached with the new
> > generation, and then if it is re-used to generate a new file system we'll
> > fail to mount it because the new fs is "older" than what we have in cache.
> > 
> > Fix this by freeing the cache when closing the device for a single device
> > filesystem. This will ensure that the mount command passed device path is
> > scanned successfully during the next mount.
> > 
> 
> Dave, I think I like this approach better actually, it may be less error prone
> than my fix, if we just delete single disks from the device cache we can remount
> whatever later.  This may be safer than what I suggested, what do you think?

Agreed, removing the single devices from cache sounds like a safe
option, the cache is there namely for multi-device fs so we don't lose
anything.
diff mbox series

Patch

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index bcfef75b97da..d024967418f6 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -403,6 +403,7 @@  void btrfs_free_device(struct btrfs_device *device)
 static void free_fs_devices(struct btrfs_fs_devices *fs_devices)
 {
 	struct btrfs_device *device;
+
 	WARN_ON(fs_devices->opened);
 	while (!list_empty(&fs_devices->devices)) {
 		device = list_entry(fs_devices->devices.next,
@@ -1181,9 +1182,22 @@  void btrfs_close_devices(struct btrfs_fs_devices *fs_devices)
 
 	mutex_lock(&uuid_mutex);
 	close_fs_devices(fs_devices);
-	if (!fs_devices->opened)
+	if (!fs_devices->opened) {
 		list_splice_init(&fs_devices->seed_list, &list);
 
+		/*
+		 * If the struct btrfs_fs_devices is not assembled with any
+		 * other device, it can be re-initialized during the next mount
+		 * without the needing device-scan step. Therefore, it can be
+		 * fully freed.
+		 */
+		if (fs_devices->num_devices == 1) {
+			list_del(&fs_devices->fs_list);
+			free_fs_devices(fs_devices);
+		}
+	}
+
+
 	list_for_each_entry_safe(fs_devices, tmp, &list, seed_list) {
 		close_fs_devices(fs_devices);
 		list_del(&fs_devices->seed_list);