Date: Mon, 26 Oct 1998 19:34:19 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: lha@e.kth.se (Love) Cc: michaelh@cet.co.jp, freebsd-fs@FreeBSD.ORG, kom-arla@stacken.kth.se Subject: Re: deadfs in FreeBSD 3.0/current ? Message-ID: <199810261934.MAA16077@usr04.primenet.com> In-Reply-To: <am3e8c6523.fsf@zinfandel.e.kth.se> from "Love" at Oct 25, 98 04:21:08 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Should we bake our own dead_vnodeops_p that is really dead vnodes ? > > > > I don't know. > > I think we dont talk about the same thing. > > All I want is a vnodeops that dead, they shouldn't do anything. We thought > that dead_vnodeops_p was written just for this, guess we was wrong. Basically, this is a revocation operation, wherein it is not possible to unwind state because the revoking entity does not own its own vnode management. > We dont want to do any special vnode management. The problem is that you are attempting the revocation at a layer that is incorrect, given the implementation of a revoked object as an instance of the object relocated to another FS type. Really, with the existance of "deadfs" instead of a "VINALID" flag inspection by upper level code, there's no way to avoid this. The one way might be to lock the vnode and bounce it up to a higher layer for invalidation/discard. > I consider it a bug if on of the vnodeops make the vfs sleep forever. It's a bug; it's just not where you think it is. > > Anyway, that's one idea. Maybe the Coda magic isn't so bad. > > I don't think to. Guess that we will build our own deadvnodeops. I would actually avoid this, if possible. It just complicates things more. Really, I'd say you should design as if deadfs did not exist, and bounce the operation to a higher level. To do the FS specific code that you must be doing in the invalidation case, you need to implement an ioctl or fcntl covert path so that the upper level can notify you to do the cleanup. If the vnode is locked before return (all vnodes *should* be locked at all times below the vnode operations call boundary, but aren't) then there is no danger of a race between an unlock and the ioctl/fcntl covert channel, and another process that is attempting to use the cached object (the cache in this case is any struct file reference to the now invalid vnode). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199810261934.MAA16077>