linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/2] btrfs: fix generic/563 failures with sectorsize < PAGE_SIZE
Date: Wed,  2 Oct 2024 11:22:32 +0930	[thread overview]
Message-ID: <cover.1727833878.git.wqu@suse.com> (raw)

The test case generic/563 always fail on 64K page sized systems with
btrfs, however there are two different causes:

- sector size == page size
  In that case, it's the test case not using aligned block size, causing
  the btrfs (and ext4) to read out the full page before buffered write.

  This is fixed by the following patch:
  https://lore.kernel.org/linux-btrfs/20240929235038.24497-1-wqu@suse.com/

- sector size < page size
  This is a problem inside btrfs, which can not handle partial uptodate
  pages, thus even if the buffered write covers a full sector, btrfs
  will still read the full page, causing unnecessary IO.
  This is btrfs specific, and ext4/xfs doesn't not have this problem.

This patchset fix the sector size < page size case for btrfs, by:

- Changing btrfs_do_readpage() to do block-by-block read
  This allows btrfs to do per-sector uptodate check, not just relying on
  the extent map checks.

- Changing both buffered read and write path to handle partial uptodate
  pages
  For the buffered write path, it's pretty straight forward, just skip
  the full page read if the range covers full sectors.

  It's the buffered read path needs the extra work, by skipping any read
  into the already uptodate sectors.

  Or we can have a dirtied range, and read (from holes) re-fill the
  dirtied range with 0, causing data corruption.

With these two patches, 4K sector sized btrfs on 64K page sized systems
can pass generic/563 now.

Although considering I have hit data corruption due to the above read
path not skipping uptodate sectors, I'm wondering should I put the full
page read skip code under EXPERIMENTAL flags.

At least this is only affecting subpage cases, the more common x86_64
cases will not be affected.

Qu Wenruo (2):
  btrfs: make btrfs_do_readpage() to do block-by-block read
  btrfs: allow buffered write to skip full page if it's sector aligned

 fs/btrfs/extent_io.c | 43 ++++++++++++++++++-------------------------
 fs/btrfs/file.c      |  5 +++--
 2 files changed, 21 insertions(+), 27 deletions(-)

-- 
2.46.2


             reply	other threads:[~2024-10-02  1:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-02  1:52 Qu Wenruo [this message]
2024-10-02  1:52 ` [PATCH 1/2] btrfs: make btrfs_do_readpage() to do block-by-block read Qu Wenruo
2024-10-02  1:52 ` [PATCH 2/2] btrfs: allow buffered write to skip full page if it's sector aligned Qu Wenruo
2024-10-09  2:57   ` 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.1727833878.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;
as well as URLs for NNTP newsgroup(s).