From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/7] btrfs: sector size < page size enhancement
Date: Mon, 25 Nov 2024 10:27:20 +1030 [thread overview]
Message-ID: <cover.1732492421.git.wqu@suse.com> (raw)
[CHANGELOG]
v2:
- Add the new fix for inline data read which can cause data corruption
Thankfully this doesn't affect any one until the last patch enabling
the partial uptodate folio support.
But it is still required before we enabling partial uptodate folio, as
a btrfs can be generated on x86_64 with inline data extents, then
booted on an aarch64 system.
- Update the double accounting fix to cover errors from
writepage_delalloc()
WHich is the missing case which can still reproduce generic/750 crash.
This series contains several sector size < page size fixes and
optimization:
- Pass generic/563 with 4k sector size and 16K/64K page size
The last patch.
The test case is a special cgroup one, which requires the fs to avoid
reading the whole folio as long as the buffered write range is btrfs
sector aligned.
- Fix generic/750 failure with 4K sector size and 16K/64K page size
It's a double ordered extent accounting for sector size < page size
cases, covering two different error paths.
The first patch.
The remaining are all preparations for the above goals.
Qu Wenruo (7):
btrfs: fix double accounting of ordered extents during errors
btrfs: fix inline data extent reads which zero out the remaining part
btrfs: extract the inner loop of cow_file_range() to enhance the error
handling
btrfs: use FGP_STABLE to wait for folio writeback
btrfs: make btrfs_do_readpage() to do block-by-block read
btrfs: avoid deadlock when reading a partial uptodate folio
btrfs: allow buffered write to skip full page if it's sector aligned
fs/btrfs/defrag.c | 6 +-
fs/btrfs/direct-io.c | 2 +-
fs/btrfs/extent_io.c | 98 +++++++----
fs/btrfs/file.c | 13 +-
fs/btrfs/inode.c | 362 +++++++++++++++++++++-------------------
fs/btrfs/ordered-data.c | 67 +++++++-
fs/btrfs/ordered-data.h | 8 +-
7 files changed, 325 insertions(+), 231 deletions(-)
--
2.47.0
next reply other threads:[~2024-11-24 23:57 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-24 23:57 Qu Wenruo [this message]
2024-11-24 23:57 ` [PATCH v2 1/7] btrfs: fix double accounting of ordered extents during errors Qu Wenruo
2024-11-24 23:57 ` [PATCH v2 2/7] btrfs: fix inline data extent reads which zero out the remaining part Qu Wenruo
2024-11-24 23:57 ` [PATCH v2 3/7] btrfs: extract the inner loop of cow_file_range() to enhance the error handling Qu Wenruo
2024-11-24 23:57 ` [PATCH v2 4/7] btrfs: use FGP_STABLE to wait for folio writeback Qu Wenruo
2024-11-24 23:57 ` [PATCH v2 5/7] btrfs: make btrfs_do_readpage() to do block-by-block read Qu Wenruo
2024-11-24 23:57 ` [PATCH v2 6/7] btrfs: avoid deadlock when reading a partial uptodate folio Qu Wenruo
2024-11-24 23:57 ` [PATCH v2 7/7] btrfs: allow buffered write to skip full page if it's sector aligned Qu Wenruo
2024-11-25 22:55 ` [PATCH v2 0/7] btrfs: sector size < page size enhancement 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=cover.1732492421.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.