From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH v3 0/2] btrfs: paramater refactors for data and metadata endio call backs
Date: Thu, 12 Nov 2020 16:47:56 +0800 [thread overview]
Message-ID: <20201112084758.73617-1-wqu@suse.com> (raw)
This is another cleanup exposed when I'm fixing my subpage patchset.
Dating back to the old time where we still have hooks for data/metadata
endio, we have a parameter called @phy_offset for both hooks.
That @phy_offset is the number of sectors compared to the bio on-disk
bytenr, and is used to grab the csum from btrfs_io_bio.
This is far from straightforward, and costs reader tons of time to grasp
the basic.
This patchset will change it by:
- Remove phy_offset completely for metadata
Since metadata doesn't use btrfs_io_bio::csums[] at all, there is no
need for it.
- Use @disk_bytenr to replace @phy_offset/@icsum
Let the callee, check_data_csum() to calculate the offset from
@disk_bytenr and bio to get the csum offset.
Changelog:
v2:
- Update commit message to remove the wrong comment on
btrfs_io_bio->logical
That logical is mess, it has different meanings for different use
cases.
What we should refer to is bio->bi_iter.bi_sector.
- Remove the false-alert prone ASSERT()
Even at endio time. bio->bi_iter.bi_size can change due to incoming
finished IOs.
This means we can't really rely on bio->bi_iter.bi_size to check if
our disk_bytenr is still valid.
v3:
- Rename the @offset/phy_offset to @bio_offset to avoid confusion
It turns out that, the name used in v2, @disk_bytenr, can also be
confusing, as in endio time, the bi_sector can be remapped for
real device offset.
Although it doesn't cause problem since we're only using that value to
calculate the offset to the beginning of the bio.
But still, we're trying to remove confusion, not adding more, thus
rename them to bio_offset.
Qu Wenruo (2):
btrfs: remove the phy_offset parameter for
btrfs_validate_metadata_buffer()
btrfs: pass bio_offset to check_data_csum() directly
fs/btrfs/disk-io.c | 2 +-
fs/btrfs/disk-io.h | 2 +-
fs/btrfs/extent_io.c | 16 +++++++++-------
fs/btrfs/inode.c | 26 ++++++++++++++++----------
4 files changed, 27 insertions(+), 19 deletions(-)
--
2.29.2
next reply other threads:[~2020-11-12 8:48 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-12 8:47 Qu Wenruo [this message]
2020-11-12 8:47 ` [PATCH v3 1/2] btrfs: remove the phy_offset parameter for btrfs_validate_metadata_buffer() Qu Wenruo
2020-11-12 9:24 ` Johannes Thumshirn
2020-11-13 18:32 ` Josef Bacik
2020-11-12 8:47 ` [PATCH v3 2/2] btrfs: pass bio_offset to check_data_csum() directly Qu Wenruo
2020-11-12 9:30 ` Johannes Thumshirn
2020-11-12 9:55 ` Nikolay Borisov
2020-11-13 18:35 ` Josef Bacik
2020-11-16 16:14 ` 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=20201112084758.73617-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