Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Boris Burkov <boris@bur.io>, Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 6/7] btrfs: btrfs_clear_delalloc_extent frees rsv
Date: Thu, 28 Mar 2024 06:09:38 +1030	[thread overview]
Message-ID: <8cd1d0e0-adcb-4f15-b0e7-b0e3b9b98ee7@gmx.com> (raw)
In-Reply-To: <20240327172640.GD2470028@zen.localdomain>



在 2024/3/28 03:56, Boris Burkov 写道:
> On Wed, Mar 27, 2024 at 08:56:20AM +1030, Qu Wenruo wrote:
>>
>>
>> 在 2024/3/27 08:09, Boris Burkov 写道:
>>> Currently, this callsite only converts the reservation. We are marking
>>> it not delalloc, so I don't think it makes sense to keep the rsv around.
>>> This is a path where we are not sure to join a transaction, so it leads
>>> to incorrect free-ing during umount.
>>>
>>> Helps with the pass rate of generic/269 and generic/475
>>
>> I guess the problem of all these ENOSPC/hutdown test cases is their
>> reproducibility.
>
> Yeah, it is definitely annoying to have to run generic/269 and
> generic/475 hundreds of times to hit various different flavors of bugs
> and try to drive it to 0. :/ It's hard to be sure that you are actually
> successful and which fixes are definitely 100% necessary.

I'm wondering if it's possible to add fsstress workload to inject errors
(to specified injection points).

IIRC we have error injection points for ENOSPC and ENOMEM, and fsstress
is so far the most reliable reproducer.

I hope that can greatly improve our reproducibility on the error paths.

>
>>
>> Unlike regular fsstress which can be very reproducible with its seed, it's
>> pretty hard to reproduce a situation where you hit a certain qgroup leak.
>>
>> Maybe the qgroup rsv leak detection is a little too strict for aborted
>> transactions?
>
> I agree for aborted transactions. It feels like a cheat just to beat the
> warning. There are many failure paths that don't end in an aborted
> transaction that we probably do actually care about, though.

Indeed, despite the aborted transactions, we still have a lot of ENOMEM
(less common though) and ENOSPC (much more common).

Thanks,
Qu
>
>>
>> Anyway, the patch itself looks fine.
>
> Thanks for all the review on this series, btw!
>
>>
>> Reviewed-by: Qu Wenruo <wqu@suse.com>
>>
>> Thanks,
>> Qu
>>>
>>> Signed-off-by: Boris Burkov <boris@bur.io>
>>> ---
>>>    fs/btrfs/inode.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>>> index 2587a2e25e44..273adbb6b812 100644
>>> --- a/fs/btrfs/inode.c
>>> +++ b/fs/btrfs/inode.c
>>> @@ -2533,7 +2533,7 @@ void btrfs_clear_delalloc_extent(struct btrfs_inode *inode,
>>>    		 */
>>>    		if (bits & EXTENT_CLEAR_META_RESV &&
>>>    		    root != fs_info->tree_root)
>>> -			btrfs_delalloc_release_metadata(inode, len, false);
>>> +			btrfs_delalloc_release_metadata(inode, len, true);
>>>    		/* For sanity tests. */
>>>    		if (btrfs_is_testing(fs_info))
>

  reply	other threads:[~2024-03-27 19:40 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26 21:39 [PATCH 0/7] btrfs: various qg meta rsv leak fixes Boris Burkov
2024-03-26 21:39 ` [PATCH 1/7] btrfs: correctly model root qgroup rsv in convert Boris Burkov
2024-03-26 22:00   ` Qu Wenruo
2024-03-27 17:20     ` Boris Burkov
2024-03-27 19:35       ` Qu Wenruo
2024-03-26 21:39 ` [PATCH 2/7] btrfs: fix qgroup prealloc rsv leak in subvolume operations Boris Burkov
2024-03-26 22:07   ` Qu Wenruo
2024-03-26 21:39 ` [PATCH 3/7] btrfs: record delayed inode root in transaction Boris Burkov
2024-03-26 22:08   ` Qu Wenruo
2024-03-27 17:21     ` Boris Burkov
2024-03-26 21:39 ` [PATCH 4/7] btrfs: convert PREALLOC to PERTRANS after record_root_in_trans Boris Burkov
2024-03-26 22:12   ` Qu Wenruo
2024-03-26 21:39 ` [PATCH 5/7] btrfs: free pertrans at end of cleanup_transaction Boris Burkov
2024-03-26 22:16   ` Qu Wenruo
2024-03-27 17:22     ` Boris Burkov
2024-03-27 19:51       ` Qu Wenruo
2024-03-26 21:39 ` [PATCH 6/7] btrfs: btrfs_clear_delalloc_extent frees rsv Boris Burkov
2024-03-26 22:26   ` Qu Wenruo
2024-03-27 17:26     ` Boris Burkov
2024-03-27 19:39       ` Qu Wenruo [this message]
2024-03-26 21:39 ` [PATCH 7/7] btrfs: always clear meta pertrans during commit Boris Burkov
2024-03-26 22:20   ` Qu Wenruo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8cd1d0e0-adcb-4f15-b0e7-b0e3b9b98ee7@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=boris@bur.io \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wqu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox