From: Boris Burkov <boris@bur.io>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: Re: [PATCH 1/5] btrfs: free qgroup rsv on ioerr ordered_extent
Date: Tue, 5 Dec 2023 11:42:25 -0800 [thread overview]
Message-ID: <ZW99IahvTeLvQ0yv@devvm9258.prn0.facebook.com> (raw)
In-Reply-To: <a72c5e7a-13ab-4f2f-8371-7ef4e2e2646e@gmx.com>
On Tue, Dec 05, 2023 at 07:34:10AM +1030, Qu Wenruo wrote:
>
>
> On 2023/12/2 07:30, Boris Burkov wrote:
> > An ordered extent completing is a critical moment in qgroup rsv
> > handling, as the ownership of the reservation is handed off from the
> > ordered extent to the delayed ref. In the happy path we release (unlock)
> > but do not free (decrement counter) the reservation, and the delayed ref
> > drives the free. However, on an error, we don't create a delayed ref,
> > since there is no ref to add. Therefore, free on the error path.
>
> And I believe this would cause btrfs to be noisy at the unmount time,
> due to unreleased qgroup rsv.
>
> Have you hit any one during your tests? If so, mind to add some dmesg
> output for it?
>
> Or if no hit so far, would it be possible to add a new test case for it?
I hit the conditions for all of these fixes running xfstests with
MKFS_OPTIONS including -O squota or -O quota. IIRC the failures were
almost all in the umount path in btrfs_check_quota_leak, though some of
the issues manifested as reservation freeing underflows in
qgroup_rsv_release. generic/475 triggered most of the bugs but a handful
of other tests hit some others. Unfortunately, I did not take perfect
notes on which test was fixed by which patch. I can try to recover that
information by removing the patches and running the full suite while
iteratively adding them back in. That is obviously fairly time consuming,
so I would only do it if people really want that information in the commit
messages or something.
Thanks for the review!
Boris
>
> >
> > Signed-off-by: Boris Burkov <boris@bur.io>
>
> Reviewed-by: Qu Wenruo <wqu@suse.com>
>
> Thanks,
> Qu
>
> > ---
> > fs/btrfs/ordered-data.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/btrfs/ordered-data.c b/fs/btrfs/ordered-data.c
> > index 574e8a55e24a..8d4ab5ecfa5d 100644
> > --- a/fs/btrfs/ordered-data.c
> > +++ b/fs/btrfs/ordered-data.c
> > @@ -599,7 +599,8 @@ void btrfs_remove_ordered_extent(struct btrfs_inode *btrfs_inode,
> > release = entry->disk_num_bytes;
> > else
> > release = entry->num_bytes;
> > - btrfs_delalloc_release_metadata(btrfs_inode, release, false);
> > + btrfs_delalloc_release_metadata(btrfs_inode, release,
> > + test_bit(BTRFS_ORDERED_IOERR, &entry->flags));
> > }
> >
> > percpu_counter_add_batch(&fs_info->ordered_bytes, -entry->num_bytes,
next prev parent reply other threads:[~2023-12-05 19:42 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-01 21:00 [PATCH 0/5] btrfs: qgroups rsv fixes Boris Burkov
2023-12-01 21:00 ` [PATCH 1/5] btrfs: free qgroup rsv on ioerr ordered_extent Boris Burkov
2023-12-04 21:04 ` Qu Wenruo
2023-12-05 19:42 ` Boris Burkov [this message]
2023-12-05 20:16 ` Qu Wenruo
2023-12-01 21:00 ` [PATCH 2/5] btrfs: fix qgroup_free_reserved_data int overflow Boris Burkov
2023-12-04 21:07 ` Qu Wenruo
2023-12-01 21:00 ` [PATCH 3/5] btrfs: free qgroup pertrans rsv on trans abort Boris Burkov
2023-12-04 21:08 ` Qu Wenruo
2023-12-05 14:27 ` David Sterba
2023-12-05 19:45 ` Boris Burkov
2023-12-05 22:39 ` David Sterba
2023-12-01 21:00 ` [PATCH 4/5] btrfs: dont clear qgroup rsv bit in release_folio Boris Burkov
2023-12-04 21:09 ` Qu Wenruo
2023-12-01 21:00 ` [PATCH 5/5] btrfs: ensure releasing squota rsv on head refs Boris Burkov
2023-12-05 17:09 ` [PATCH 0/5] btrfs: qgroups rsv fixes David Sterba
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=ZW99IahvTeLvQ0yv@devvm9258.prn0.facebook.com \
--to=boris@bur.io \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo.btrfs@gmx.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