From owner-freebsd-fs Mon Oct 26 11:25:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA11304 for freebsd-fs-outgoing; Mon, 26 Oct 1998 11:25:59 -0800 (PST) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA11297; Mon, 26 Oct 1998 11:25:57 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id MAA02283; Mon, 26 Oct 1998 12:25:00 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp01.primenet.com, id smtpd002094; Mon Oct 26 12:24:44 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id MAA15542; Mon, 26 Oct 1998 12:24:38 -0700 (MST) From: Terry Lambert Message-Id: <199810261924.MAA15542@usr04.primenet.com> Subject: Re: deadfs in FreeBSD 3.0/current ? To: art@stacken.kth.se (Artur Grabowski) Date: Mon, 26 Oct 1998 19:24:37 +0000 (GMT) Cc: lha@s3.kth.se, freebsd-fs@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG, kom-arla@stacken.kth.se In-Reply-To: from "Artur Grabowski" at Oct 25, 98 03:51:52 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > kern/vfs_subr.c:vclean() does a vp->v_flag |= VXLOCK; and after that > > "calls" VOP_LOCK(). > > > > Now when the filesystem is deadfs (we use it in arla[1]), the call > > ends up in miscfs/deadfs/dead_vnops.c:dead_lock() that calls > > chkvnlock(). Now chkvnlock() sleeps when VXLOCK is set. > > As a horrible workaround in OpenBSD I noted that LK_DRAIN is set in the > VOP_LOCK call in vclean. (The code is not checked in, our tree is locked). > And when the LK_DRAIN is set I don't do the chkvnlock(). Oh, look. People have started trying to do real work in the VFS code, and the first thing that rears its ugly head is a stacking layer issue that I identified about three years ago. As a workaround for the brain-damage in this area, look at the handling of vnodes of type VT_TFS, since TFS handles it's own vnode pool by severability rather than by correction of the interface bogosity. 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