From owner-freebsd-fs Sat Dec 22 13: 8:26 2001 Delivered-To: freebsd-fs@freebsd.org Received: from elvis.mu.org (elvis.mu.org [216.33.66.196]) by hub.freebsd.org (Postfix) with ESMTP id 4E0A337B41A; Sat, 22 Dec 2001 13:08:20 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id C590B81E0C; Sat, 22 Dec 2001 15:08:14 -0600 (CST) Date: Sat, 22 Dec 2001 15:08:14 -0600 From: Alfred Perlstein To: Ian Dowse Cc: mckusick@freebsd.org, fs@freebsd.org Subject: Re: fsck and predictive readahead? Message-ID: <20011222150814.Z48837@elvis.mu.org> References: <20011222053306.Y48837@elvis.mu.org> <200112221353.aa41047@salmon.maths.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200112221353.aa41047@salmon.maths.tcd.ie>; from iedowse@maths.tcd.ie on Sat, Dec 22, 2001 at 01:53:11PM +0000 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org * Ian Dowse [011222 07:53] wrote: > 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. The problem you didn't address with all these changes was stalls due to disk IO. /usr/src/sbin/fsck_ffs # time ./fsck_ffs -d -n /vol/spare ** /dev/ad0s1g (NO WRITE) ** Last Mounted on /vol/spare ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 303580 files, 12865338 used, 9183427 free (51827 frags, 1141450 blocks, 0.2% fragmentation) ./fsck_ffs -d -n /vol/spare 24.50s user 4.72s system 19% cpu 2:30.73 total No matter how you order the IO, fsck is going to have to wait for read(2) to return. If we can offload that waiting to a child process we may be able to fix this. Is there any detailed commenting on the sources available, they are quite readable, but still very terse. A more in depth explanation of each function would really help. Do you know of a paper, manpage or do you have the time to sprinkle some commentary into the code? -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' http://www.morons.org/rants/gpl-harmful.php3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message