From owner-freebsd-current Tue Apr 8 03:31:45 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id DAA29773 for current-outgoing; Tue, 8 Apr 1997 03:31:45 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id DAA29751; Tue, 8 Apr 1997 03:31:36 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.5/CET-v2.1) with SMTP id KAA10828; Tue, 8 Apr 1997 10:30:00 GMT Date: Tue, 8 Apr 1997 19:29:59 +0900 (JST) From: Michael Hancock Reply-To: Michael Hancock To: Terry Lambert cc: current@FreeBSD.ORG, freebsd-fs@FreeBSD.ORG Subject: Re: DISCUSS: vnode references as open instances In-Reply-To: <199704032343.QAA17773@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 Terry, I think it will be hard to get support to change ufs this drastically at this time since Kirk is working on soft updates. And there is also quite of a bit of community interest in having a trusted stable fs implementation to fall back on. How you considered what Netcom? did with tfs? It seems they use their own vnode allocation scheme. I vaguely remember seeing changes made to allow this. If you wanted to make even more radical changes Heidemann's papers discuss using a compatibility layer between the consumer of the old interface and a new framework. This would give you more leeway for big changes like reimplementing ufs without the outdated cylinder group layout stuff, etc. I know it's easier said then done and there might be some restrictions, but I think you would get more support with this strategy. Regards, Mike Hancock On Thu, 3 Apr 1997, Terry Lambert wrote: > I am looking for discussion, pro and con. > > ----------------------------------------------------------------------------- > > I believe that vnode references should be treated as counting > semaphores. > > Currently, reference holders are net required to count references > in all cases. > > The purpose of this change would be to significantly clean up > the vnode reference interactions to provide a meaningful > seperation between vnode maintenance and vnode reclamation, > with the eventual intention of removing the need for vclean() > and the duplication of code in each per FS VOP_LOCK implementation. > > > This change would affect the directory name lookup cache code > (for which a vnode reference in a cache would be very much the > same as an open instance for a vnode reference by a system open > file table reference), as well as several other subsystems. > > > Though vnodes are currently globally accounted, I beleive that > there should be a per FS interface, initially to the global > accounting interface, for freeing vnodes in an FS specific > manner. > > The eventual intent of this change is to allow per-FS management > of vnodes as part of the FS's [*,i]node pool, and to therefore > relieve the need for global vnode pool management, and thus global > recovery of vnodes for reuse. > > > This would be similar in scope to the SVR4 vnode management scheme, > as described in "The Magic Garden Explained" and the _Bach_ book. > > > One large benefit of this technique would be to allow the recovery > of unreferenced vnodes from per FS "second chance" caches, like > the FFS "ihash" facility, and therfore the recovery of perfectly > valid memory pages that refere to a referenced per FS object. > > Currently, there is no recovery mechanism whereby the valid pages > can be re-referenced for use once the vnode had been disassociated > from the per-FS object, but not from the valid pages. > > When a reference which references these pages occurs, the data, > though in core, cannot be reclaimed, and must be reread from > disk. > > ----------------------------------------------------------------------------- > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > -- michaelh@cet.co.jp http://www.cet.co.jp CET Inc., Daiichi Kasuya BLDG 8F 2-5-12, Higashi Shinbashi, Minato-ku, Tokyo 105 Japan Tel: +81-3-3437-1761 Fax: +81-3-3437-1766