Date: Sun, 25 Oct 1998 23:57:09 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Love <lha@e.kth.se> Cc: freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? Message-ID: <Pine.BSF.3.95LJ1.1b3.981025232452.1677A-100000@sv01.cet.co.jp> In-Reply-To: <amiuh867zl.fsf@zinfandel.e.kth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
[bugs trimmed] On 25 Oct 1998, Love wrote: > > 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 ? I don't know. Our vnode constructors/destructors are handled by central code for all file systems. It's pretty intertwined in the VFS and VOP layers. Having this global policy provided good memory utilization, but it isn't very flexible. I was looking at this a while ago and was thinking of putting the vnode management into the VFS layer so that a file system could have the option to manage its own vnodes or just wrap the default stuff: getnewvnode, vput, vrele, vclean, vgone, VOP_INACTIVE, etc. We already have a VFS_VGET which wraps getnewvnode, but this is for a specific case where you need to get a vnode given an inode. You would need to make something like VFS_VALLOC, and maybe VFS_(VRELE|VPUT). This way you could make it so that you had your own pool of vnodes that never get vclean'ed and retyped as another file system vnode. I started doing VFS_VRELE, but you need to bring in the VFS infrastructure, like mount.h, all over the VOP code for each file system implementation. After working with a little bit I realized that it needed to be thought out more and then I got to busy to follow-up on it. You might be able to take a different approach by holding ref counts and doing some tricks with VOP_INACTIVE on the destructor side. We'd be hosed if active vnodes were revoked, but I'm not sure if this really happens anymore. I wish I had the time to go back and do the analysis and design. Anyway, that's one idea. Maybe the Coda magic isn't so bad. Regards, Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95LJ1.1b3.981025232452.1677A-100000>