From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/2] btrfs: fix data corruption/hang/rsv leak in subpage zoned cases
Date: Wed, 6 Mar 2024 09:05:32 +1030 [thread overview]
Message-ID: <cover.1709677986.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Update the commit message for the first patch
As there is something wrong with the ASCII art of the memory layout.
[REPO]
https://github.com/adam900710/linux/tree/subpage_delalloc
The repo includes the subpage delalloc rework, or subpage zoned won't
work at all.
Although my previous subpage delalloc rework fixes quite a lot of
crashes of subpage + zoned support, it's still pretty easy to cause rsv
leak using single thread fsstress.
It turns out that, it's not a simple problem of some rsv leak, but
certain dirty data ranges never got written back and just skipped with
its dirty flags cleared, no wonder that would lead to rsv leak.
The root cause is again in the extent_write_locked_range() function
doing weird subpage incompatible behaviors, especially when it clears
the page dirty flag for the whole page, causing __extent_writepage_io()
unable to locate any dirty ranges to be submitted.
The first patch would solve the problem, meanwhile for the 2nd patch
it's a cleanup, as we will never hit the error for current subpage +
zoned cases.
Qu Wenruo (2):
btrfs: do not clear page dirty inside extent_write_locked_range()
btrfs: make extent_write_locked_range() to handle subpage writeback
correctly
fs/btrfs/extent_io.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
--
2.44.0
next reply other threads:[~2024-03-05 22:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-05 22:35 Qu Wenruo [this message]
2024-03-05 22:35 ` [PATCH v2 1/2] btrfs: do not clear page dirty inside extent_write_locked_range() Qu Wenruo
2024-05-10 14:25 ` Josef Bacik
2024-05-12 8:56 ` Qu Wenruo
2024-03-05 22:35 ` [PATCH v2 2/2] btrfs: make extent_write_locked_range() to handle subpage writeback correctly Qu Wenruo
2024-05-10 14:25 ` Josef Bacik
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=cover.1709677986.git.wqu@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/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