From owner-freebsd-current Fri Aug 2 10:06:36 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id KAA16694 for current-outgoing; Fri, 2 Aug 1996 10:06:36 -0700 (PDT) Received: from minnow.render.com (render.demon.co.uk [158.152.30.118]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id KAA16687 for ; Fri, 2 Aug 1996 10:06:33 -0700 (PDT) Received: from minnow.render.com (minnow.render.com [193.195.178.1]) by minnow.render.com (8.6.12/8.6.9) with SMTP id SAA28686; Fri, 2 Aug 1996 18:06:44 +0100 Date: Fri, 2 Aug 1996 18:06:44 +0100 (BST) From: Doug Rabson To: Terry Lambert cc: jkh@time.cdrom.com, tony@fit.qut.edu.au, freebsd-current@freebsd.org Subject: Re: NFS Diskless Dispare... In-Reply-To: <199608021615.JAA05802@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Fri, 2 Aug 1996, Terry Lambert wrote: > > [snip] > > > > I think the worst races would be between VOP_READ or VOP_WRITE and vclean. > > I think that you could cause real damage with one of those :-). > > I had a vclean patch to deal with the "free vnode isn't" error a long > time ago... it was a serious kludge, IMO, since it fixed the symptom > instead of the problem (which is that vclean is a bad idea). I think > the patch would also save us from the race conditions as well. Are you > maybe thinking of client side nfsnodes? I was thinking of an NFS client race where a process could be sleeping in NFS waiting for an rpc reply and vclean could cut in and start tearing thing up. If vclean manages to sleep part way through, then interesting things could start to happen... -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 251 4411 FAX: +44 171 251 0939