Date: Wed, 26 Dec 2001 11:15:05 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Alfred Perlstein <bright@mu.org> Cc: Ian Dowse <iedowse@maths.tcd.ie>, mckusick@freebsd.org, fs@freebsd.org Subject: Re: fsck and predictive readahead? Message-ID: <3C2A21B9.428C3800@mindspring.com> References: <20011222053306.Y48837@elvis.mu.org> <200112221353.aa41047@salmon.maths.tcd.ie> <20011222150814.Z48837@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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). -- Terry 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?3C2A21B9.428C3800>