From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH RFC 0/2] btrfs: remove the metadata readahead mechanism
Date: Tue, 7 Dec 2021 15:43:58 +0800 [thread overview]
Message-ID: <20211207074400.63352-1-wqu@suse.com> (raw)
This is originally just my preparation for scrub refactors, but when the
readahead is involved, it won't just be a small cleanup.
The metadata readahead code is introduced in 2011 (surprisingly, the
commit message even contains changelog), but now only one user for it,
and even for the only one user, the readahead mechanism can't provide
much help in fact.
Scrub needs readahead for commit root, but the existing one can only do
current root readahead.
And the code is at a very bad layer inside btrfs, all metadata are at
btrfs logical address space, but the readahead is kinda working at
device layer (to manage the in-flight readahead).
Personally speaking, I don't think such "optimization" is really even
needed, since we have better way like setting IO priority.
I really prefer to let the professional block layer guys do whatever
they are good at (and in fact, those block layer guys rock!).
Immature optimization is the cause of bugs, and it has already caused
several bugs recently.
Nowadays we have btrfs_path::reada to do the readahead, I doubt if we
really need such facility.
So here I purpose to completely remove the old and under utilized
metadata readahead system.
Qu Wenruo (2):
btrfs: remove the unnecessary path parameter for scrub_raid56_parity()
btrfs: remove reada mechanism
fs/btrfs/Makefile | 2 +-
fs/btrfs/ctree.h | 25 -
fs/btrfs/dev-replace.c | 5 -
fs/btrfs/disk-io.c | 20 +-
fs/btrfs/extent_io.c | 3 -
fs/btrfs/reada.c | 1086 ----------------------------------------
fs/btrfs/scrub.c | 64 +--
fs/btrfs/super.c | 1 -
fs/btrfs/volumes.c | 7 -
fs/btrfs/volumes.h | 7 -
10 files changed, 17 insertions(+), 1203 deletions(-)
delete mode 100644 fs/btrfs/reada.c
--
2.34.1
next reply other threads:[~2021-12-07 7:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 7:43 Qu Wenruo [this message]
2021-12-07 7:43 ` [PATCH RFC 1/2] btrfs: remove the unnecessary path parameter for scrub_raid56_parity() Qu Wenruo
2021-12-07 7:44 ` [PATCH RFC 2/2] btrfs: remove reada mechanism Qu Wenruo
2021-12-07 11:02 ` [PATCH RFC 0/2] btrfs: remove the metadata readahead mechanism Filipe Manana
2021-12-07 11:43 ` Qu Wenruo
2021-12-07 11:56 ` Filipe Manana
2021-12-07 12:01 ` Qu Wenruo
2021-12-07 14:53 ` David Sterba
2021-12-07 15:40 ` David Sterba
2021-12-07 15:53 ` Filipe Manana
2021-12-08 0:08 ` Qu Wenruo
2021-12-08 14:04 ` David Sterba
2021-12-09 10:25 ` Filipe Manana
2021-12-09 13:25 ` Qu Wenruo
2021-12-09 14:33 ` Josef Bacik
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=20211207074400.63352-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