From owner-freebsd-arch Mon Feb 10 4: 1:33 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B04B37B401 for ; Mon, 10 Feb 2003 04:01:32 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 759BA43F93 for ; Mon, 10 Feb 2003 04:01:31 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0003.cvx22-bradley.dialup.earthlink.net ([209.179.198.3] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18iCcq-0007Kx-00; Mon, 10 Feb 2003 04:01:29 -0800 Message-ID: <3E479440.D89E90F5@mindspring.com> Date: Mon, 10 Feb 2003 04:00:00 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: phk@phk.freebsd.dk Cc: David Schultz , arch@FreeBSD.ORG Subject: Re: Our lemming-syncer caught in the act. References: <37473.1044868995@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4fd7664590b0d84904e7a5b02e442166fa8438e0f32a48e08350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG phk@phk.freebsd.dk wrote: > 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. Are there any statistics on how many requests are prevented by soft updates? Maybe you are really talking about a value that would be best expressed as a ratio? It seems to me that this would be a necessary part of any changes made on the basis of instrumentation that might decrease the interval, but increase the absolute number of requests, as a result. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message