Patch "btrfs: do not output error message if a qgroup has been already cleaned up" has been added to the 6.13-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    btrfs: do not output error message if a qgroup has been already cleaned up

to the 6.13-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     btrfs-do-not-output-error-message-if-a-qgroup-has-be.patch
and it can be found in the queue-6.13 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit 88af943149cf5a32f92246e0e952fb47d08f7862
Author: Qu Wenruo <wqu@xxxxxxxx>
Date:   Mon Jan 20 09:40:43 2025 +1030

    btrfs: do not output error message if a qgroup has been already cleaned up
    
    [ Upstream commit c9c863793395cf0a66c2778a29d72c48c02fbb66 ]
    
    [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@xxxxxxxxx>
    Link: https://bugzilla.suse.com/show_bug.cgi?id=1236056
    Fixes: 839d6ea4f86d ("btrfs: automatically remove the subvolume qgroup")
    Reviewed-by: Filipe Manana <fdmanana@xxxxxxxx>
    Signed-off-by: Qu Wenruo <wqu@xxxxxxxx>
    Reviewed-by: David Sterba <dsterba@xxxxxxxx>
    Signed-off-by: David Sterba <dsterba@xxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
index 993b5e803699e..5ab51781d0e4f 100644
--- a/fs/btrfs/qgroup.c
+++ b/fs/btrfs/qgroup.c
@@ -1915,8 +1915,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;
 }




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux