From: Boris Burkov <boris@bur.io>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH v4 0/6] btrfs: fix corruption caused by partial dio writes
Date: Tue, 21 Mar 2023 09:45:27 -0700 [thread overview]
Message-ID: <cover.1679416511.git.boris@bur.io> (raw)
The final patch in this series ensures that bios submitted by btrfs dio
match the corresponding ordered_extent and extent_map exactly. As a
result, there is no hole or deadlock as a result of partial writes, even
if the write buffer is a partly overlapping mapping of the range being
written to.
This required a bit of refactoring and setup. Specifically, the zoned
device code for "extracting" an ordered extent matching a bio could be
reused with some refactoring to return the new ordered extents after the
split.
Patch 1: Generic patch for returning an ordered extent while creating it
Patch 2: Cache the dio ordered extent so that we can efficiently detect
partial writes during bio submission, without an extra lookup.
Patch 3: Light refactoring of split_zoned_em -> split_em
Patch 4: Use Patch 1 to track the new ordered_extent(s) that result from
splitting an ordered_extent.
Patch 5: Fix a bug in ordered extent splitting
Patch 6: Use the new more general split logic of Patch 4 and the stashed
ordered extent from Patch 2 to split partial dio bios to fix
the corruption while avoiding the deadlock.
---
Changelog:
v4:
- significant changes; redesign the fix to use bio splitting instead of
extending the ordered_extent lifetime across calls into iomap.
- all the oe/em splitting refactoring and fixes
v3:
- handle BTRFS_IOERR set on the ordered_extent in btrfs_dio_iomap_end.
If the bio fails before we loop in the submission loop and exit from
the loop early, we never submit a second bio covering the rest of the
extent range, resulting in leaking the ordered_extent, which hangs umount.
We can distinguish this from a short write in btrfs_dio_iomap_end by
checking the ordered_extent.
v2:
- rename new ordered extent function
- pull the new function into a prep patch
- reorganize how the ordered_extent is stored/passed around to avoid so
many annoying memsets and exposing it to fs/btrfs/file.c
- lots of small code style improvements
- remove unintentional whitespace changes
- commit message improvements
- various ASSERTs for clarity/debugging
Boris Burkov (6):
btrfs: add function to create and return an ordered extent
btrfs: stash ordered extent in dio_data during iomap dio
btrfs: repurpose split_zoned_em for partial dio splitting
btrfs: return ordered_extent splits from bio extraction
btrfs: fix crash with non-zero pre in btrfs_split_ordered_extent
btrfs: split partial dio bios before submit
fs/btrfs/bio.c | 2 +-
fs/btrfs/btrfs_inode.h | 5 +-
fs/btrfs/inode.c | 185 +++++++++++++++++++++++++++++-----------
fs/btrfs/ordered-data.c | 88 ++++++++++++++-----
fs/btrfs/ordered-data.h | 13 ++-
5 files changed, 214 insertions(+), 79 deletions(-)
--
2.38.1
next reply other threads:[~2023-03-21 16:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-21 16:45 Boris Burkov [this message]
2023-03-21 16:45 ` [PATCH v4 1/6] btrfs: add function to create and return an ordered extent Boris Burkov
2023-03-21 16:45 ` [PATCH v4 2/6] btrfs: stash ordered extent in dio_data during iomap dio Boris Burkov
2023-03-21 16:45 ` [PATCH v4 3/6] btrfs: repurpose split_zoned_em for partial dio splitting Boris Burkov
2023-03-21 20:33 ` Boris Burkov
2023-03-21 16:45 ` [PATCH v4 4/6] btrfs: return ordered_extent splits from bio extraction Boris Burkov
2023-03-21 16:45 ` [PATCH v4 5/6] btrfs: fix crash with non-zero pre in btrfs_split_ordered_extent Boris Burkov
2023-03-21 16:45 ` [PATCH v4 6/6] btrfs: split partial dio bios before submit Boris Burkov
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.1679416511.git.boris@bur.io \
--to=boris@bur.io \
--cc=kernel-team@fb.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