Date: Tue, 27 Aug 1996 12:35:14 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: vclean (was The VIVA file system) Message-ID: <Pine.SV4.3.93.960827115155.17910A-100000@parkplace.cet.co.jp> In-Reply-To: <199608270220.TAA23773@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 26 Aug 1996, Terry Lambert wrote: > > I think what needs to be looked at is having more synchronized buffer > > cache/vnode recycling policies. > > Inode data, disklabel data, and any other FS object which is not file > contents is not cached under the current policy. The vnode/inode association with a vnhash() you mentioned before makes sense. I wonder how hard it would be to manage the buffer cache/vnodes/inodes with more synergy (sorry I couldn't think of a better word). > Further, dissociating buffers from vnodes does not require that they > be returned to a global pool for clean-behind. There's an in-place free list that can have valid buffers hanging off of them and vnodes go on the list when inactive() is called. I guess the freelist should be called the inactive list. getnewvnode() vgone() vclean() should only be called when it needs to, such as when file activity moves to a different fs and there aren't enough vnodes. The vnode pool was a fixed size pool in lite, but someone put in a malloc() into getnewvnode(). The vnode pool is kind of wired so I think it can now grow, but it can't shrink unless there's some free()s being done somewhere where I haven't noticed. > I think the non-opacity of vnodes is a mistake. I guess they didn't have time to get this aspect right. Some of the semantics are very interesting though, they look very different from the SysV vnodes I read about in the Vahalia book. Regards, Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.93.960827115155.17910A-100000>