From: Andrew Price <anprice@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH 2/2] fsck.gfs2: Improve read ahead in pass1_process_bitmap
Date: Fri, 11 Sep 2015 12:35:04 +0100 [thread overview]
Message-ID: <1441971304-31556-2-git-send-email-anprice@redhat.com> (raw)
In-Reply-To: <1441971304-31556-1-git-send-email-anprice@redhat.com>
The read ahead strategy in this function was pretty naive, it just read
in all of the inode blocks, in block-sized reads, before doing any
processing. In my tests with a full filesystem, removing this read ahead
actually sped up the tests, presumably due to issuing a large number of
small I/Os and not keeping them cached. Moving the read ahead into the
processing loop and reading ahead by larger chunks after certain periods
gave improved performance. After some experimentation, I found the best
performance was given by reading ahead 100 blocks after every 50 inodes
processed. Timings were:
Master Without R.A. With this patch
51:03.41 48:07.40 47:13.66
50:56.45 48:07.42 47:01.04
51:02.25 48:00.06 47:05.72
I would expect the performance gain to be larger on filesystems with a
higher density of inode blocks.
Signed-off-by: Andrew Price <anprice@redhat.com>
---
gfs2/fsck/pass1.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/gfs2/fsck/pass1.c b/gfs2/fsck/pass1.c
index c0f2f1e..653be59 100644
--- a/gfs2/fsck/pass1.c
+++ b/gfs2/fsck/pass1.c
@@ -1532,17 +1532,22 @@ static int pass1_process_bitmap(struct gfs2_sbd *sdp, struct rgrp_tree *rgd, uin
uint64_t block;
struct gfs2_inode *ip;
uint8_t q;
+ /* Readahead numbers arrived at by experiment */
+ unsigned rawin = 50;
+ unsigned ralen = 100 * sdp->bsize;
+ unsigned r = 0;
- /* Issue read-ahead for all dinodes in this bitmap */
- for (i = 0; i < n; i++)
- posix_fadvise(sdp->device_fd, ibuf[i] * sdp->bsize, sdp->bsize,
- POSIX_FADV_WILLNEED);
for (i = 0; i < n; i++) {
int is_inode;
uint32_t check_magic;
block = ibuf[i];
+ if (r++ == rawin) {
+ posix_fadvise(sdp->device_fd, block * sdp->bsize, ralen, POSIX_FADV_WILLNEED);
+ r = 0;
+ }
+
/* skip gfs1 rindex indirect blocks */
if (sdp->gfs1 && blockfind(&gfs1_rindex_blks, block)) {
log_debug(_("Skipping rindex indir block "
--
2.4.3
prev parent reply other threads:[~2015-09-11 11:35 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-11 11:35 [Cluster-devel] [PATCH 1/2] fsck.gfs2: Really be quiet in quiet mode Andrew Price
2015-09-11 11:35 ` Andrew Price [this message]
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=1441971304-31556-2-git-send-email-anprice@redhat.com \
--to=anprice@redhat.com \
/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).