linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [RFC PATCH v2 0/3] e2fsck metadata prefetch
@ 2014-02-01 10:37 Darrick J. Wong
  2014-02-01 10:37 ` [PATCH 1/3] ext2fs: add readahead method to improve scanning Darrick J. Wong
                   ` (2 more replies)
  0 siblings, 3 replies; 9+ messages in thread
From: Darrick J. Wong @ 2014-02-01 10:37 UTC (permalink / raw)
  To: tytso, darrick.wong; +Cc: linux-ext4

This is the second go at a patchset that tries to reduce e2fsck run
times by pre-loading ext4 metadata concurrent with e2fsck execution.
The first patch is Andreas Dilger's patch to add a readahead method to
the IO manager interface.  The second patch extends libext2fs with a
function call to invoke readahead on a list of blocks, and a second
call that invokes readahead on the bitmaps and inode tables of a bunch
of groups.  The third patch enhances e2fsck to start threads that call
the readahead functions.

Crude testing has been done via:
# echo 3 > /proc/sys/vm/drop_caches
# READAHEAD=1 /usr/bin/time ./e2fsck/e2fsck -Fnfvtt /dev/XXX

So far in my crude testing on a cold system, I've seen about a ~20%
speedup on a SSD, a ~40% speedup on a 3x RAID1 SATA array, and maybe
a 5% speedup on a single-spindle SATA disk.  On a single-queue USB
HDD, performance doesn't change much.  It looks as though in general,
single-spindle HDDs will not benefit, which doesn't surprise me.  The
SSD numbers are harder to quantify since they're already fast.

This second version of the patch uses posix_fadvise to hint to the
kernel that it really wants to have the blocks loaded in the page
cache ready to go.  This is much easier to manage, because all we need
to do is throw a list of blocks at it and let it go... and if we're
careful not to change any FS state, we can easily offload the
readahead work to a thread without weird crashes.

Note that this draft code does little to prevent page cache thrashing.
It doesn't hold back from issuing a large flood of IO.  It's not clear
if it's better to try to constrain how far the prefetcher gets ahead
of the checker code, or better to let the kernel sort it out.

I've tested these e2fsprogs changes against the -next branch as of
1/31.  These days, I use an 8GB ramdisk and whatever hardware I have
lying around.  The make check tests should pass.

Comments and questions are, as always, welcome.

--D

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-02-04  1:26 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-01 10:37 [RFC PATCH v2 0/3] e2fsck metadata prefetch Darrick J. Wong
2014-02-01 10:37 ` [PATCH 1/3] ext2fs: add readahead method to improve scanning Darrick J. Wong
2014-02-01 10:37 ` [PATCH 2/3] libext2fs: allow clients to read-ahead metadata Darrick J. Wong
2014-02-01 10:41   ` Darrick J. Wong
2014-02-03 21:32   ` Andreas Dilger
2014-02-03 23:26     ` Darrick J. Wong
2014-02-01 10:37 ` [PATCH 3/3] e2fsck: read-ahead metadata during pass1 and pass2 Darrick J. Wong
2014-02-03 21:20   ` Andreas Dilger
2014-02-04  1:26     ` Darrick J. Wong

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).