From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 0/3] btrfs: btrfs_lookup_bio_sums() related fixes
Date: Wed, 28 Oct 2020 15:24:29 +0800 [thread overview]
Message-ID: <20201028072432.86907-1-wqu@suse.com> (raw)
This is the final piece to make subpage read/write patchset to pass all
fsstress tests.
Before this 3 patches, there is a very low chance to hit the following
errors:
- False bad data csum error
The expected csum is alwasy 0x00000000, which should represents
something.
- WARN_ON_ONCE(count) hit
Something is definitely wrong in btrfs_lookup_bio_sums().
After more debugging, even on X86_64, there is definitely something to
notice, the most important thing is, the bvec in btrfs_lookup_bio_sums()
is not always in linear bytenr order:
btrfs_lookup_bio_sums: file_offset=-1 expected_bvec_offset=532480 page_offset=716800 bv_offset=0
btrfs_lookup_bio_sums: orig_file_offset=520192 bvec_index=3 root=259 ino=260 page_owner_ino=260
This is from x86_64 run, with extra debug info from the
bio_for_each_segment() loop.
It shows that, also the bio->bi_size is correct and each page is
properly mapped, they are not ensured to be in bytenr order.
This could ruin subpage support, if we hit a bvec which belongs to the
end of the bio, and we found a lot of csums for it, we may skip the
csums for other bvecs.
To address the problem, the 3rd patch is introduced to do bio unrelated
csum search.
This does not only simplify the main loop (just one small main loop),
but also free us from the out-of-order bvec problems.
The other two patches are mostly small enhancement found during the
development.
With the patchset, the subpage can survice (mostly) infinite fsstress
run and the regular page size case can still pass all existing fstests.
Since it has nothing special to subpage at all, and by nature they are
mostly renames and refactor, they can be submitted right now, with or
without subpage patches.
Qu Wenruo (3):
btrfs: file-item: use nodesize to determine whether we need readhead
for btrfs_lookup_bio_sums()
btrfs: ordered-data: rename parameter @len to @nr_sectors
btrfs: file-item: refactor btrfs_lookup_bio_sums() to handle
out-of-order bvecs
fs/btrfs/file-item.c | 242 ++++++++++++++++++++++++----------------
fs/btrfs/ordered-data.c | 9 +-
fs/btrfs/ordered-data.h | 2 +-
3 files changed, 154 insertions(+), 99 deletions(-)
--
2.29.1
next reply other threads:[~2020-10-29 2:45 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 7:24 Qu Wenruo [this message]
2020-10-28 7:24 ` [PATCH 1/3] btrfs: file-item: use nodesize to determine whether we need readhead for btrfs_lookup_bio_sums() Qu Wenruo
2020-10-29 7:25 ` Nikolay Borisov
2020-10-28 7:24 ` [PATCH 2/3] btrfs: ordered-data: rename parameter @len to @nr_sectors Qu Wenruo
2020-10-29 7:32 ` Nikolay Borisov
2020-11-03 19:16 ` David Sterba
2020-11-03 19:23 ` Amy Parker
2020-11-03 23:36 ` Qu Wenruo
2020-10-28 7:24 ` [PATCH 3/3] btrfs: file-item: refactor btrfs_lookup_bio_sums() to handle out-of-order bvecs Qu Wenruo
2020-11-03 19:46 ` David Sterba
2020-11-03 23:42 ` Qu Wenruo
2020-11-16 16:27 ` David Sterba
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=20201028072432.86907-1-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).