From owner-freebsd-fs Sun Oct 25 06:18:30 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA16017 for freebsd-fs-outgoing; Sun, 25 Oct 1998 06:18:30 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from elixir.e.kth.se (elixir.e.kth.se [130.237.48.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id GAA16001; Sun, 25 Oct 1998 06:18:25 -0800 (PST) (envelope-from lha@s3.kth.se) Received: from zinfandel.e.kth.se (1073744992@zinfandel.e.kth.se [130.237.48.172]) by elixir.e.kth.se (8.8.7/8.8.7) with ESMTP id PAA23255; Sun, 25 Oct 1998 15:17:50 +0100 (MET) Received: (lha@localhost) by zinfandel.e.kth.se (8.8.7/8.6.6) id PAA22897; Sun, 25 Oct 1998 15:17:50 +0100 (MET) To: Michael Hancock Cc: freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? References: From: Love Date: 25 Oct 1998 15:17:50 +0100 In-Reply-To: Michael Hancock's message of Sun, 25 Oct 1998 20:49:38 +0900 (JST) Message-ID: Lines: 38 X-Mailer: Gnus v5.5/Emacs 20.2 Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 ? Love To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message