[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: Breaking ffs - speed enhancement?
From:       "Jonathan M. Bresler" <jmb>
Date:       1996-05-31 22:49:43
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread]