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