linux-kernel - Re: [patch 00/14] Page cache cleanup in anticipation of Large Blocksize support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070614164118.cbd48e53.akpm@linux-foundation.org>
Date:	Thu, 14 Jun 2007 16:41:18 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	David Chinner <dgc@....com>
Cc:	clameter@....com, linux-kernel@...r.kernel.org, hch@...radead.org
Subject: Re: [patch 00/14] Page cache cleanup in anticipation of Large
 Blocksize support

> On Fri, 15 Jun 2007 09:30:02 +1000 David Chinner <dgc@....com> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/