Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Mar 1998 18:59:17 +0900 (JST)
From:      Michael Hancock <michaelh@cet.co.jp>
To:        current@FreeBSD.ORG
Subject:   Re: vnode_pager: *** WARNING *** stale FS code in system
Message-ID:  <Pine.SV4.3.95.980309172219.21097H-100000@parkplace.cet.co.jp>
In-Reply-To: <19980309082056.A13758@keltia.freenix.fr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 9 Mar 1998, Ollivier Robert wrote:

> > What effort?  Yours?  I dont see anyone working on the FS stacking
> > effort.

I started recently.  Mike Smith committed some glue recently.  The next
round of patches will give some immediate gratification.

People have been working on stacking in our tree since April 97 as far as
I can tell and have made some progress.  I think BSDI has spent quite a
bit of time with FS stacking too.

What I found surprising is that no one put a higher priority on some
fundamental stuff like releasing memory and lock state at the same layer
as they were acquired.  Imagine trying to map a returning vpp that was
vrele'd, or worse vgone'd, before it reached your layer.  Kirk says that
this is one of the first things that should be done.

Regularizing wasn't done when the VFS layer was inserted in the middle
because the pre-VFS code was written that way and I guess the various
people working on it found it expedient to just leave it the way it was.
It wasn't as much of an issue in pre-VFS days.

I'm working on this now for the most visible offenders.  My next round of
patches will fix the dvp argument rele behavior of VOP_CREATE, VOP_MKNOD,
VOP_MKDIR, and VOP_SYMLINK.  My initial target was just VOP_CREATE, but my
list has grown as I discovered dependencies.

So far lock state doesn't look like a problem to fix either, but I'll
tackle it later after all the rele behavior has been fixed for all
offending VOPs.  I'm looking for special cases while working on this
sweep.

This divide and conquer grunt work has paid off in other ways, I've found
a missing vput in DEVFS's symlink implementation and let Julian know. 

Terry's argument for making nameidata "reflexive" is the same issue.

Regards,



Mike Hancock


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.980309172219.21097H-100000>