From owner-freebsd-fs Mon Aug 26 20:35:45 1996 Return-Path: owner-fs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA03980 for fs-outgoing; Mon, 26 Aug 1996 20:35:45 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA03935; Mon, 26 Aug 1996 20:35:35 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id DAA18200; Tue, 27 Aug 1996 03:35:15 GMT Date: Tue, 27 Aug 1996 12:35:14 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: eric@ms.uky.edu, freebsd-fs@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: vclean (was The VIVA file system) In-Reply-To: <199608270220.TAA23773@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-fs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk 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