> On Fri, 15 Jun 2007 09:30:02 +1000 David Chinner <[EMAIL PROTECTED]> wrote: > On Thu, Jun 14, 2007 at 03:04:17PM -0700, Andrew Morton wrote: > > fsck is single-threaded (hence no locking issues) and operates against the > > blockdev pagecache and does a _lot_ of small reads (indirect blocks, > > especially). > > Commenting purely about the above statement (and not on large pages > or block sizes), xfs-repair has had multithreaded capability for some > time now. E.g. from the xfs_repair man page: > > -M Disable multi-threaded mode. Normally, xfs_repair runs with > twice the number of threads as processors. > > > We have the second generation multithreading code out for review > right now. e.g: > > http://oss.sgi.com/archives/xfs/2007-06/msg00069.html > > xfs_repair also uses direct I/O and does it's own userspace block > caching and so avoids the problems involved with low memory, context > unaware cache reclaim and blockdev cache thrashing.
umm, that sounds like a mistake to me. fscks tend to get run when there's no swap online. A small system with a large disk risks going oom and can no longer be booted. Whereas if the fsck relies upon kernel caching it'll run slower but will complete. > And to top it all off, some of the prefetch smarts we added result > in reading multiple sparse metadata blocks in a single, larger I/O, > so repair is now often bandwidth bound rather than seek bound... > > All I'm trying to say here is that you shouldn't assume that the > problems a particular filesystem fsck has is common to all the > rest.... Yup. I was of course referring to fsck.extN. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
