From owner-freebsd-hackers Fri May 31 14:45:22 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA21150 for hackers-outgoing; Fri, 31 May 1996 14:45:22 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA21123 for ; Fri, 31 May 1996 14:45:17 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id OAA18810; Fri, 31 May 1996 14:40:24 -0700 From: Terry Lambert Message-Id: <199605312140.OAA18810@phaeton.artisoft.com> Subject: Re: Breaking ffs - speed enhancement? To: davidg@Root.COM Date: Fri, 31 May 1996 14:40:24 -0700 (MST) Cc: terry@lambert.org, rashid@rk.ios.com, jgreco@solaria.sol.net, hackers@FreeBSD.ORG In-Reply-To: <199605292032.NAA02323@Root.COM> from "David Greenman" at May 29, 96 01:32:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > >There is a school of thought that says "shall be updated" in POSIX is > >not the same as "shall be committed to stable storage" (the traditional > >BSD implementation). > > > >This would let access times be updated in core, but only scheduled to > >be written at a later time (not forced out immediately). > > They already are updated in-core and only written out during sync. The > problem is that on busy machines, *thousands* of inodes have to be written > out during the sync, and this can take 10+ seconds. With sync occuring every > 30 seconds, this means the machine spends 33% of it's disk I/O time *just* > writing out inodes. The access time is almost completely useless on a busy > fileserver, so this is just a waste. That they are writen out during sync instead of being LRU'ed out is *the* problem. The sync does not have a sufficiently long cycle time for decent write-gathering. It doesn't help that since the cache is by vnode/offset instead of device/offset, non-vnode-contents data is not really cached the same way at all; it tends to have a much higher flush rate than is desirable. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.