All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] btrfs: free device in btrfs_close_devices for a single device filesystem
@ 2023-01-20 13:47 Anand Jain
  2023-01-30 19:34 ` Josef Bacik
  0 siblings, 1 reply; 3+ messages in thread
From: Anand Jain @ 2023-01-20 13:47 UTC (permalink / raw)
  To: linux-btrfs; +Cc: Daan De Meyer, Josef Bacik

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(-)

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);
-- 
2.38.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] btrfs: free device in btrfs_close_devices for a single device filesystem
  2023-01-20 13:47 [PATCH] btrfs: free device in btrfs_close_devices for a single device filesystem Anand Jain
@ 2023-01-30 19:34 ` Josef Bacik
  2023-02-07 16:04   ` David Sterba
  0 siblings, 1 reply; 3+ messages in thread
From: Josef Bacik @ 2023-01-30 19:34 UTC (permalink / raw)
  To: dsterba; +Cc: Anand Jain, linux-btrfs, Daan De Meyer

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] btrfs: free device in btrfs_close_devices for a single device filesystem
  2023-01-30 19:34 ` Josef Bacik
@ 2023-02-07 16:04   ` David Sterba
  0 siblings, 0 replies; 3+ messages in thread
From: David Sterba @ 2023-02-07 16:04 UTC (permalink / raw)
  To: Josef Bacik; +Cc: dsterba, Anand Jain, linux-btrfs, Daan De Meyer

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.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-02-07 16:10 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-01-20 13:47 [PATCH] btrfs: free device in btrfs_close_devices for a single device filesystem Anand Jain
2023-01-30 19:34 ` Josef Bacik
2023-02-07 16:04   ` David Sterba

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.