Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 May 1996 14:40:24 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        davidg@Root.COM
Cc:        terry@lambert.org, rashid@rk.ios.com, jgreco@solaria.sol.net, hackers@FreeBSD.ORG
Subject:   Re: Breaking ffs - speed enhancement?
Message-ID:  <199605312140.OAA18810@phaeton.artisoft.com>
In-Reply-To: <199605292032.NAA02323@Root.COM> from "David Greenman" at May 29, 96 01:32:29 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> >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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605312140.OAA18810>