Re: [PATCH 4/4] btrfs: swallow btrfs_record_squota_delta() enoent

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

在 2026/5/13 05:04, Boris Burkov 写道:
> 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.
> 
> Signed-off-by: Boris Burkov <boris@bur.io>
> ---
>   fs/btrfs/qgroup.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/qgroup.c b/fs/btrfs/qgroup.c
> index a93d49015fc7..f9e5005028dc 100644
> --- a/fs/btrfs/qgroup.c
> +++ b/fs/btrfs/qgroup.c
> @@ -4959,7 +4959,7 @@ 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;
> +		ret = 0;

I appreciate that end users won't be bothered with transaction abort, 
but on the other hand, this seems to mask real bugs.

Can we add a WARN_ON_ONCE(IS_ENABLED(CONFIG_BTRFS_DEBUG))) so that we 
can catch such problems for debug builds?

Thanks,
Qu>   		goto out;
>   	}
>