Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v2 0/3] btrfs: fix generic/362 failures with nodatasum
Date: Sat, 30 May 2026 13:04:16 +0930	[thread overview]
Message-ID: <cover.1780112003.git.wqu@suse.com> (raw)

Changelog
v2:
- Add a new patch to allow retry after no byte is submitted for direct
  write

- Add a more clean callchain to explain why __iomap_dio_rw() doesn't
  return -EFAULT/-ENOTBLK directly.

- Add a code comment explaining the OE split sitation and why we can
  truncate all the remaining OE after a short write

- Fix the isize revert when part of the direct write succeeded

- Dig deeper into the original cause
  Which is very old, dates back to v5.15 LTS at least, and add a reason
  why no specific fixes tag is provided.

The test case generic/362 is pretty well hidden by several factors:

- "nodatasum" will not take effect due to the bad design of the test
  case
  If the target file already exists, the test case will reuse it,
  meanwhile "nodatasum" mount option only affects new files, meaning
  if the test case is executed before with data checksum, it will never
  go through the nodatasum path.

  There is already an update on the test case to make the failure
  reliably reproducible:
  https://lore.kernel.org/linux-btrfs/20260528111659.87113-1-wqu@suse.com/

- Btrfs always falls back to buffered IO if the inode has csum
  Thus we do not exercise the zero-copy path, hide the failure for the
  default mount option.

With that said, the test case failure needs to be fixed, and there are
several bugs in the direct write path:

- Treat any short write as an error
  This is especially common as we have disabled page faulting for
  reading from the @from iov_iter.

  This is fixed by the first patch.

- No isize rollback after a short write
  The isize is increased at btrfs_get_blocks_direct_write() but when a
  short write happened, the isize is not propoerly rolledback, causing
  later buffered fallback to write at the new isize.

  This is fixed by the second patch.

- No page fault-in retry after a zero-submitted short write
  Unlike the previous two, this is only a minor problem which reduces
  the chance to do zero-copy direct IO.

  This is fixed by the third patch.

Qu Wenruo (3):
  btrfs: fix false IO failure after falling back to buffered write
  btrfs: fix incorrect buffered IO fallback for append direct writes
  btrfs: retry faulting in the pages after a zero sized short direct
    write

 fs/btrfs/direct-io.c    | 44 ++++++++++++++++++++++++++++++++++++-----
 fs/btrfs/inode.c        |  6 +-----
 fs/btrfs/ordered-data.c | 12 +++++++++++
 fs/btrfs/ordered-data.h |  2 ++
 4 files changed, 54 insertions(+), 10 deletions(-)

-- 
2.54.0


             reply	other threads:[~2026-05-30  3:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-30  3:34 Qu Wenruo [this message]
2026-05-30  3:34 ` [PATCH v2 1/3] btrfs: fix false IO failure after falling back to buffered write Qu Wenruo
2026-05-30  3:34 ` [PATCH v2 2/3] btrfs: fix incorrect buffered IO fallback for append direct writes Qu Wenruo
2026-05-30  3:34 ` [PATCH v2 3/3] btrfs: retry faulting in the pages after a zero sized short direct write 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.1780112003.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