Skip site navigation (1)Skip section navigation (2)
Date:      25 Oct 1998 15:17:50 +0100
From:      Love <lha@e.kth.se>
To:        Michael Hancock <michaelh@cet.co.jp>
Cc:        freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se
Subject:   Re: deadfs in FreeBSD 3.0/current ?
Message-ID:  <amiuh867zl.fsf@zinfandel.e.kth.se>
In-Reply-To: Michael Hancock's message of Sun, 25 Oct 1998 20:49:38 %2B0900 (JST)
References:  <Pine.BSF.3.95LJ1.1b3.981025202548.1224A-100000@sv01.cet.co.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
Michael Hancock <michaelh@cet.co.jp> writes:

> On 25 Oct 1998, Love wrote:
> 
> > But that is done *after* the tsleep, and therefor that code will *never* be
> > reached. Kind of hard to wake yourself up. It will hang in
> > miscfs/deadfs/dead_vnops.c(1.24):240 forever.
> 
> Umm...  Why are you using deadfs in arla?  I think you're breaking an
> invariant if vclean is trying to clean out something that's already dead.
> Kinda like a double free.
>
>Sorry, let me guess.  You're trying to cache vnodes but the kernel wants
>to control the lifetime of vnodes.  With the global vnode management
>policy and how deadfs works this is tricky.  You might want to look at how
>the Coda people solved this, I don't have a clue.

Arla is like coda (http://www.coda.cs.cmu.edu/) and has a userland daemon
that keeps track of all things, the kernel module does caching to keep the
speed up. But then the userland-daemon is dead you have to return something
in the kernel-module so we do:

    return getnewvnode(VT_NON, mp, dead_vnodeop_p, vpp);}

Because we don't want to do magic with xfs_vnodeops_p when there is no
userland daemon, they do that with coda.

So you have a deadvnodeops that isn't really vnodeops or what (just used the
small timeframe from when a vnode is vclean()ed to its assigned to a new
filesystem by checkalias(), vflush(), or vgonel() ?)

Should we bake our own dead_vnodeops_p that is really dead vnodes ?

Love





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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?amiuh867zl.fsf>