From owner-freebsd-fs Wed Dec 26 11:20:38 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 D803537B417; Wed, 26 Dec 2001 11:20:34 -0800 (PST) Received: by elvis.mu.org (Postfix, from userid 1192) id 8750981D01; Wed, 26 Dec 2001 13:20:34 -0600 (CST) Date: Wed, 26 Dec 2001 13:20:34 -0600 From: Alfred Perlstein To: Terry Lambert Cc: Ian Dowse , mckusick@freebsd.org, fs@freebsd.org Subject: Re: fsck and predictive readahead? Message-ID: <20011226132034.N91594@elvis.mu.org> References: <20011222053306.Y48837@elvis.mu.org> <200112221353.aa41047@salmon.maths.tcd.ie> <20011222150814.Z48837@elvis.mu.org> <3C2A21B9.428C3800@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3C2A21B9.428C3800@mindspring.com>; from tlambert2@mindspring.com on Wed, Dec 26, 2001 at 11:15:05AM -0800 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 * Terry Lambert [011226 13:15] wrote: > Alfred Perlstein wrote: > > ./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? > > There's a paper on fsck in /usr/share, and it's also in the Usenix > published books (I can share them with you, if you need me to). Thanks, I'll have a look at the paper, I'll let you know if I need more from your references. > The easiest way to handle this would be with a windowed mmap(), > with the other process being given either atonomy to read one > byte per page, predictively, or the calculation ahead. Then > the pages would be in core by the time the first process needed > them, and then all we are talking about is mapping. > > This really looks like a job for rfork(), rather than another > process, or true threads, so that the address space is shared, > and there is not a remapping requirement (PTE thrashing would > potentially slow you down with any other approach). Agreed, first I'd like to see how it performs if I can get the IO done. Perhaps aio, but that's kinda icky. :) -- -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.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message