Date: Mon, 10 Feb 2003 01:50:40 -0800 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: phk@phk.freebsd.dk Cc: arch@FreeBSD.ORG Subject: Re: Our lemming-syncer caught in the act. Message-ID: <20030210095040.GB5515@HAL9000.homeunix.com> In-Reply-To: <37473.1044868995@critter.freebsd.dk> References: <20030210091317.GD5165@HAL9000.homeunix.com> <37473.1044868995@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake phk@phk.freebsd.dk <phk@phk.freebsd.dk>: > In message <20030210091317.GD5165@HAL9000.homeunix.com>, David Schultz writes: > > >When a large file times out, a significant amount of I/O can be > >generated. This is still far better than the old syncer that > >flushed everything every 30 seconds. The reasons for this > >behavior are explained in src/sys/ufs/ffs/README. After reading > >that, do you still think it makes sense to try to do better? > > Yes, it makes a lot of sense. There is no point in batching up > writes to the point of showing 200 requests off at once then > wait 30 seconds, then do it again etc etc. > > We can and need to do better than that. It sounds like you're describing the old syncer. The new one still shoves groups of buffers out at once, but on a file-by-file basis rather than globally every 30 seconds. (Maybe that's what you meant.) To fix the problem correctly, you would probably need to track the timeouts on each individual buffer and pay the extra management overhead. Alternatively, perhaps it would be possible to ``pace'' files that have large numbers of dirty buffers associated with them. You could extend softdep_fsync() by adding an additional argument specifying the maximum number of buffers to write, so that when a large file times out, it can be staggered over several runs of the syncer (which is activated every second.) Kirk would be a good person to talk to, I think. By the way, can you see what effect lowering the following sysctls has? John Dyson reported that the default timeouts are well into diminishing returns for improving performance, and a few months ago I actually saw a small but measurable performance *increase* with the values below: kern.filedelay: 7 kern.dirdelay: 6 kern.metadelay: 5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030210095040.GB5515>