]> git.ipfire.org Git - thirdparty/kernel/linux.git/commitdiff
btrfs: swallow btrfs_record_squota_delta() ENOENT
authorBoris Burkov <boris@bur.io>
Tue, 12 May 2026 16:55:28 +0000 (09:55 -0700)
committerDavid Sterba <dsterba@suse.com>
Sat, 16 May 2026 01:08:40 +0000 (03:08 +0200)
I thought that it was likely I could harden squota deletion to the point
that it was impossible to end up with an extent accounted to a qgroup
outliving its qgroup. Several recent bugs have made me re-consider that
position.

Ultimately, this is a tradeoff between short term stability and long
term strictness, but I think given that there could be another layer of
bugs behind the 2-3 I just fixed, I would feel much more confident in
people using squotas if the risk was "your values can get a bit out of
whack which you can fix by deleting stuff or
disabling/re-enabling/repairing" vs "it will abort your filesystem".

As the final nail in the coffin, the Meta production kernel was lacking
earlier fixes from me and Qu regarding subvol qgroup lifetime, so this
is what we have been testing at scale, so I think at least for now
upstream should have the same extra layer of protection.

Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Boris Burkov <boris@bur.io>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/qgroup.c

index e9e7091e1452f57baa206bf76f0280659e05c9c3..6838faceb6d5c09725ff76d6e983fb7f921fb60d 100644 (file)
@@ -4957,8 +4957,9 @@ int btrfs_record_squota_delta(struct btrfs_fs_info *fs_info,
 
        spin_lock(&fs_info->qgroup_lock);
        qgroup = find_qgroup_rb(fs_info, root);
-       if (!qgroup) {
-               ret = -ENOENT;
+       if (WARN_ON_ONCE(!qgroup)) {
+               btrfs_warn(fs_info, "squota failed to find qgroup for root %llu", root);
+               ret = 0;
                goto out;
        }