From owner-freebsd-fs@FreeBSD.ORG  Mon Apr 11 16:15:45 2005
Return-Path: <owner-freebsd-fs@FreeBSD.ORG>
Delivered-To: freebsd-fs@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8504716A4CE
	for <freebsd-fs@freebsd.org>; Mon, 11 Apr 2005 16:15:45 +0000 (GMT)
Received: from ns.cygnus.de (ns.cygnus.de [194.221.99.19])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0C39043D45
	for <freebsd-fs@freebsd.org>; Mon, 11 Apr 2005 16:15:44 +0000 (GMT)
	(envelope-from gth@cmex.de)
Received: from [192.168.1.4] (p54995C39.dip.t-dialin.net [84.153.92.57])
	j3BGUGS19710
	for <freebsd-fs@freebsd.org>; Mon, 11 Apr 2005 18:30:17 +0200
X-Authentication-Warning: ns.cygnus.de: Host p54995C39.dip.t-dialin.net
	[84.153.92.57] claimed to be [192.168.1.4]
From: Gunther Thiel <gth@cmex.de>
To: freebsd-fs@freebsd.org
Message-Id: <1113236140.685.33.camel@darthvader>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.6 
Date: Mon, 11 Apr 2005 18:15:40 +0200
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Content-Filtered-By: Mailman/MimeDel 2.1.1
Subject: Stackable Filesystems/deadlock/VI_DOOMED
X-BeenThere: freebsd-fs@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Filesystems <freebsd-fs.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-fs>
List-Post: <mailto:freebsd-fs@freebsd.org>
List-Help: <mailto:freebsd-fs-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-fs>,
	<mailto:freebsd-fs-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2005 16:15:45 -0000

I am working on stackable filesystems using 5.3-STABLE and figured that 
there are still deadlock problems when using the nullfs template on a
busy, stressed machine.
>From what I have experienced, apparently the deadlock occurs when trying
to get a new node while it's being recycled.

What I have seen in the VFS code of the CURRENT branch looks very
promising (VI_DOOMED instead of VI_XLOCK!), but as I have no clue when
new VFS stuff will be in a solid state, I wanted to ask if the problem
is at all solveable with the VFS concept under 5.3 and if so, how.
If it is not solveable (which is my personal guess) would someone mind
giving me a hint on dependencies when I would only like to use as much
stuff from CURRENT to move to new VFS concept (with all the ostentatious
risks)?

Thanks very much!
Gunther