| Message ID | d538309bf9cbfb732b4f9c3bc174ccdcfe9ccafa.1737328208.git.wqu@suse.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | btrfs: do not output error message if a qgroup is already cleaned up | expand |
On Sun, Jan 19, 2025 at 11:11 PM Qu Wenruo <wqu@suse.com> wrote: > > [BUG] > There is a bug report that btrfs outputs the following error message: > > BTRFS info (device nvme0n1p2): qgroup scan completed (inconsistency flag cleared) > BTRFS warning (device nvme0n1p2): failed to cleanup qgroup 0/1179: -2 > > [CAUSE] > The error itself is pretty harmless, and the end user should ignore it. > > When a subvolume is fully dropped, btrfs will call > btrfs_qgroup_cleanup_dropped_subvolume() to delete the qgroup. > > However if a qgroup rescan happened before a subvolume fully dropped, > qgroup for that subvolume will not be re-created, as rescan will only > create new qgroup if there is a BTRFS_ROOT_REF_KEY found. > > But before we drop a subvolume, the subvolume is unlinked thus there is no > BTRFS_ROOT_REF_KEY. > > In that case, btrfs_remove_qgroup() will fail with -ENOENT and trigger > the above error message. > > [FIX] > Just ignore -ENOENT error from btrfs_remove_qgroup() inside > btrfs_qgroup_cleanup_dropped_subvolume(). > > Reported-by: John Shand <jshand2013@gmail.com> > Link: https://bugzilla.suse.com/show_bug.cgi?id=1236056 > Fixes: 839d6ea4f86d ("btrfs: automatically remove the subvolume qgroup") > Signed-off-by: Qu Wenruo <wqu@suse.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Looks good, thanks. > --- > fs/btrfs/qgroup.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c > index b90fabe302e6..aaf16019d829 100644 > --- a/fs/btrfs/qgroup.c > +++ b/fs/btrfs/qgroup.c > @@ -1897,8 +1897,11 @@ int btrfs_qgroup_cleanup_dropped_subvolume(struct btrfs_fs_info *fs_info, u64 su > /* > * It's squota and the subvolume still has numbers needed for future > * accounting, in this case we can not delete it. Just skip it. > + * > + * Or the qgroup is already removed by a qgroup rescan. For both cases we're > + * safe to ignore them. > */ > - if (ret == -EBUSY) > + if (ret == -EBUSY || ret == -ENOENT) > ret = 0; > return ret; > } > -- > 2.48.0 > >
diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c index b90fabe302e6..aaf16019d829 100644 --- a/fs/btrfs/qgroup.c +++ b/fs/btrfs/qgroup.c @@ -1897,8 +1897,11 @@ int btrfs_qgroup_cleanup_dropped_subvolume(struct btrfs_fs_info *fs_info, u64 su /* * It's squota and the subvolume still has numbers needed for future * accounting, in this case we can not delete it. Just skip it. + * + * Or the qgroup is already removed by a qgroup rescan. For both cases we're + * safe to ignore them. */ - if (ret == -EBUSY) + if (ret == -EBUSY || ret == -ENOENT) ret = 0; return ret; }
[BUG] There is a bug report that btrfs outputs the following error message: BTRFS info (device nvme0n1p2): qgroup scan completed (inconsistency flag cleared) BTRFS warning (device nvme0n1p2): failed to cleanup qgroup 0/1179: -2 [CAUSE] The error itself is pretty harmless, and the end user should ignore it. When a subvolume is fully dropped, btrfs will call btrfs_qgroup_cleanup_dropped_subvolume() to delete the qgroup. However if a qgroup rescan happened before a subvolume fully dropped, qgroup for that subvolume will not be re-created, as rescan will only create new qgroup if there is a BTRFS_ROOT_REF_KEY found. But before we drop a subvolume, the subvolume is unlinked thus there is no BTRFS_ROOT_REF_KEY. In that case, btrfs_remove_qgroup() will fail with -ENOENT and trigger the above error message. [FIX] Just ignore -ENOENT error from btrfs_remove_qgroup() inside btrfs_qgroup_cleanup_dropped_subvolume(). Reported-by: John Shand <jshand2013@gmail.com> Link: https://bugzilla.suse.com/show_bug.cgi?id=1236056 Fixes: 839d6ea4f86d ("btrfs: automatically remove the subvolume qgroup") Signed-off-by: Qu Wenruo <wqu@suse.com> --- fs/btrfs/qgroup.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)