Date: Fri, 31 May 1996 15:49:43 -0700 (PDT) From: "Jonathan M. Bresler" <jmb> To: terry@lambert.org (Terry Lambert) Cc: davidg@Root.COM, terry@lambert.org, rashid@rk.ios.com, jgreco@solaria.sol.net, hackers@FreeBSD.org Subject: Re: Breaking ffs - speed enhancement? Message-ID: <199605312249.PAA15899@freefall.freebsd.org> In-Reply-To: <199605312140.OAA18810@phaeton.artisoft.com> from "Terry Lambert" at May 31, 96 02:40:24 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote: > > > >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. > [caveat: i am getting deeper into filesystems but have a long way to go yet. please add a grain of salt to these comments.] how is our current file system different from that used in 4.2BSD? i assume that we are now using extent based clustering similar to that described by McVoy and Kleiman in "Extent-like Performance of a Unix File System". if so then increasing the update interval should have significant benefits in reducing the I/O soaked by inodes (metadata) updates. would this give us a quasi-asych filesystem? one where we could delay update to fit our tolerance for letting the metedata "hang out in the wind"? trace driven anaysis of 4.2 BSD FFS shows that increasing the update time to 5 min reduces I/O sharply. most files are short-lived. this is the same phenomemon that makes -pipe such a win in compilations. > 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. no comment at this time, your honor. ;) jmb -- Jonathan M. Bresler FreeBSD Postmaster jmb@FreeBSD.ORG FreeBSD--4.4BSD Unix for PC clones, source included. http://www.freebsd.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605312249.PAA15899>