On Mon, 12 Nov 2007 20:12:37 -0500
Thor Lancelot Simon <tls@rek.tjls.com> wrote:

> On Tue, Nov 13, 2007 at 12:18:17AM +0000, Steven M. Bellovin wrote:
> > On Mon, 12 Nov 2007 20:38:10 +0000 (UTC)
> > mlelstv@serpens.de (Michael van Elst) wrote:
> > > 
> > > The problem comes from running out of buffers. You want to sync
> > > often and you want to sync fewer buffers in a burst to mitigate
> > > the problem.
> > 
> > This, I think, is a large part of the actual solution to the
> > problem. The other part is to have the process scheduler penalize
> > processes -- or users? -- that do too much I/O.
> 
> Well, yes.  But even just the first part would suffice.  The basic
> problem with softdep, and with the "smooth" syncer we got with it, is
> that it schedules all the I/O enqueued in a second to be synced out
> at some second xdelay seconds in the future, for each of the few
> types of metadata I/O x. Worse, it tracks metadata I/O to be done in
> the future by vnode, and it attaches most metadata I/O to the mount
> point's own vnode, so it all gets crammed together.  And there's no
> way to track processes that cause metadata I/O, so you can't really
> penalize them.
> 
I never said it was easy -- I've been muttering about this for O(30
years)....  The issue is read contention, not just write contention, in
many cases.

I deleted the rest of your post because I agree with it completely....


		--Steve Bellovin, http://www.cs.columbia.edu/~smb