aboutsummaryrefslogtreecommitdiffstats
path: root/scripts/generate_rust_target.rs
diff options
context:
space:
mode:
authorQu Wenruo <[email protected]>2025-01-19 23:10:43 +0000
committerDavid Sterba <[email protected]>2025-01-23 21:34:11 +0000
commitc9c863793395cf0a66c2778a29d72c48c02fbb66 (patch)
tree2838281351fbae889088cd4ff193892c726f7658 /scripts/generate_rust_target.rs
parentbtrfs: fix assertion failure when splitting ordered extent after transaction ... (diff)
downloadkernel-c9c863793395cf0a66c2778a29d72c48c02fbb66.tar.gz
kernel-c9c863793395cf0a66c2778a29d72c48c02fbb66.zip
btrfs: do not output error message if a qgroup has been already cleaned up
[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 <[email protected]> Link: https://bugzilla.suse.com/show_bug.cgi?id=1236056 Fixes: 839d6ea4f86d ("btrfs: automatically remove the subvolume qgroup") Reviewed-by: Filipe Manana <[email protected]> Signed-off-by: Qu Wenruo <[email protected]> Reviewed-by: David Sterba <[email protected]> Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'scripts/generate_rust_target.rs')
0 files changed, 0 insertions, 0 deletions