From owner-freebsd-bugs Sun Oct 25 07:25:44 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA20267 for freebsd-bugs-outgoing; Sun, 25 Oct 1998 07:25:44 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from bg.sics.se (bg.sics.se [193.10.66.124]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id HAA20248; Sun, 25 Oct 1998 07:25:40 -0800 (PST) (envelope-from bg@bg.sics.se) Received: (from bg@localhost) by bg.sics.se (8.8.5/8.8.5) id QAA29863; Sun, 25 Oct 1998 16:27:25 +0100 (CET) To: Love Cc: Michael Hancock , freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Bjoern Groenvall Date: 25 Oct 1998 16:27:25 +0100 In-Reply-To: Love's message of 25 Oct 1998 15:17:50 +0100 Message-ID: Lines: 50 X-Mailer: Red Gnus v0.52/Emacs 19.34 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Love writes: > Michael Hancock 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 ? In the evil old days when I wrote xfs; dead vnodes was only used to be able to unmount xfs when there was no user space daemon running. Is it still required to have a root vnode to be able to unmount? If not, you no longer need that hack, it's enough to have xfs_root fail. Cheers, Björn -- _ _ ,_______________. Bjorn Gronvall (Björn Grönvall) /_______________/| Swedish Institute of Computer Science | || PO Box 1263, S-164 29 Kista, Sweden | Schroedingers || Email: bg@sics.se, Phone +46 -8 633 15 25 | Cat |/ Cellular +46 -70 768 06 35, Fax +46 -8 751 72 30 `---------------' To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message