From owner-freebsd-current Wed Aug 28 17:30:30 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA18534 for current-outgoing; Wed, 28 Aug 1996 17:30:30 -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 RAA18471; Wed, 28 Aug 1996 17:30:08 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id AAA04895; Thu, 29 Aug 1996 00:29:07 GMT Date: Thu, 29 Aug 1996 09:29:07 +0900 (JST) From: 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: <199608281650.JAA26928@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Wed, 28 Aug 1996, Terry Lambert wrote: > > > This was the point I was missing. What is disassociating the inode and > > > when is it happening? > > > > Yikes! I took a look below, but I didn't expect to see vgone() calls in > > ufs_inactive(). > > > > if (vp->v_usecount == 0 && ip->i_mode == 0) > > vgone(vp); > > > > I need to figure out what ip->i_mode == 0 means. > > The file type is a non-zero value in the high bits of the mode word; > it means that the inode does not refer to real data any more. > > The vgone call is just part of the subsystem I think should be replaced > wholesale; I'd like to see a per FS vrele() (back to locally managed > pools) replace most of those calls. The vgone() calls vgone1() calls > vclean, and we're back in my hate-zone. My interpretation of the vnode global pool design was that vgone...->vclean wouldn't be called very often. It would only be called by getnewvnode() when free vnodes were not available and for cases when the vnode is deliberately revoked. Inactive() would mark both the vnode/inode inactive, but the data would be left intact even when usecount went to zero so that all the important data could be reactivated quickly. It's not working this way and it doesn't look trivial to get it work this way. Regarding local per fs pools you still need some kind of global memory management policy. It seems less complicated to manage a global pool, than local per fs pools with opaque VOP calls. Say you've got FFS, LFS, and NFS systems mounted and fs usage patterns migrate between the fs's. You've got limited memory resources. How do you determine which local pool to recover vnodes from? It'd be inefficient to leave the pools wired until the fs was unmounted. Complex LRU-like policies across multiple local per fs vnode pools also sound pretty complicated to me. We also need to preserve the vnode revoking semantics for situations like revoking the session terminals from the children of sesssion leaders. Regards, Mike Hancock