Date: Sat, 22 Dec 2001 13:53:11 +0000 From: Ian Dowse <iedowse@maths.tcd.ie> To: Alfred Perlstein <bright@mu.org> Cc: mckusick@freebsd.org, fs@freebsd.org Subject: Re: fsck and predictive readahead? Message-ID: <200112221353.aa41047@salmon.maths.tcd.ie> In-Reply-To: Your message of "Sat, 22 Dec 2001 05:33:06 CST." <20011222053306.Y48837@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20011222053306.Y48837@elvis.mu.org>, Alfred Perlstein writes: >I'm wondering if fsck uses any sort of tricks to do read-ahead >to prefect data for pass1 and pass2. > >If not does anyone thing it might speed things up? I've wondered about this also. Since fsck spends virtually all of its time waiting for disk reads, doing most kinds of speculative disk reads would only slow things down. However, there is some potential for re-ordering the reads to reduce seeking and to allow data to be read in larger chunks. Pass 1 involves quite a lot of disk seeking because it goes off and retrieves all indirection blocks (blocks of block numbers) for any inodes that have them. Otherwise pass 1 would be a simple linear scan through all inodes. It would be possible to defer the reading of indirection blocks and then read them in order (having 2nd- and 3rd-level indirection blocks complicates this). I think I tried a simple form of this a few years ago, but the speedup was only marginal. I believe I also tried changing fsck's bread() to read larger blocks when contiguous reads were detected, again with no significant improvements. For pass 2, the directories are sorted by the block number of their first block, so there is very little seeking. Some speed improvement might be possible by doing a larger read when a few directory blocks are close together on the disk. An interesting exercise would be to modify fsck to print out a list of the offset and length for every disk read it performs. Then sort that list, coalesce contiguous reads, and see how long it takes the disk to read the new list as compared to the original. Such perfect sorting is obviously not feasable in practice, but it would give some idea of the potential for improvements. Ian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi? <200112221353.aa41047>