From owner-freebsd-fs@FreeBSD.ORG Thu Feb 15 14:56:43 2007 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B470C16A402 for ; Thu, 15 Feb 2007 14:56:43 +0000 (UTC) (envelope-from tol@pdc.kth.se) Received: from mx2.kth.se (mx2.kth.se [130.237.48.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4252C13C48E for ; Thu, 15 Feb 2007 14:56:43 +0000 (UTC) (envelope-from tol@pdc.kth.se) Received: from localhost (localhost.localdomain [127.0.0.1]) by mx2.kth.se (Postfix) with ESMTP id 2680C14082B; Thu, 15 Feb 2007 15:56:42 +0100 (CET) Received: from mx2.kth.se ([127.0.0.1]) by localhost (mx2.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31130-01-67; Thu, 15 Feb 2007 15:56:39 +0100 (CET) Received: from kashyyyk.ite.kth.se (kashyyyk.ite.kth.se [130.237.31.35]) by mx2.kth.se (Postfix) with ESMTP id 3E54614081E; Thu, 15 Feb 2007 15:56:39 +0100 (CET) Received: by kashyyyk.ite.kth.se (Postfix, from userid 18404) id F0B8489CA62; Thu, 15 Feb 2007 15:56:38 +0100 (CET) Sender: tol@kashyyyk.ite.kth.se From: Tomas Olsson To: Kostik Belousov References: <20070214162938.GA96725@keira.kiwi-computer.com> <20070214173211.L1054@chrishome.localnet> <20070214170808.GC96725@keira.kiwi-computer.com> <20070215044707.GA39168@deviant.kiev.zoral.com.ua> <20070215104537.GC39168@deviant.kiev.zoral.com.ua> <20070215120855.GE39168@deviant.kiev.zoral.com.ua> <20070215134608.GG39168@deviant.kiev.zoral.com.ua> Date: 15 Feb 2007 15:56:38 +0100 In-Reply-To: <20070215134608.GG39168@deviant.kiev.zoral.com.ua> Message-ID: Lines: 48 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at kth.se Cc: freebsd-fs@freebsd.org, arla-drinkers@stacken.kth.se Subject: Re: Arla on FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 14:56:43 -0000 Kostik Belousov writes: > On Thu, Feb 15, 2007 at 02:07:19PM +0100, Tomas Olsson wrote: > > Ok, vn_open() must be passed curthread so we can't use arlad's thread when > > in our VOP. And we cannot use an absolute path to the cache. So vn_open() > > can't be used? > vn_open() does not need curthread in strong sence, but td is the thread > that all locks and sleeps will be performed for. > Except in places like vput() and vrele()? struct thread *td = curthread; /* XXX */ > I think that your current strategy would work, but it needs to be checked. > Nice. Possibly there are still a few places where I mix contexts too much as well. And I've probably missed a few mandatory support routines along the lines of vn_start_write(). > > So where does this leave us, is plain lookup() (or VOP_LOOKUP) and > > VOP_CREATE on the cache a possible way to go? Seems to work on OpenBSD. > vn_open() is the right way. Otherwise, you would in fact reimplement the > code from it. > I know, I just don't see how to get around it. > Also, you could look at file handle API, that would save you of path lookups > after the vnode is looked up first time (look around for vfs_vptofh and > vfs_fhtovp ops). This API is used by NFS server, so it shall work :). > That's an idea. We used that before in another context, but then we ran into trouble with too many OSes so we dropped it. Depends on how much code one can share. > > Well, it's marked "doesn't need giant"; we use our own global lock. I don't > > trust it 100%, but it seems to work so far. I haven't tried it on any MP > > FreeBSD boxes though. > > Again, this could lead to lock order reversals with vnode lock. For > instance, when lookup() traverses tree, it has the parent directory > locked and calls fs-provided VOP_LOOKUP(). This method shall return the > leaf vnode locked. Since, according to you claim, some alra-specific > global lock is taken between these two vnode locks, it could LOR between > vnode locks and alra lock > I'm not sure if that's currently a problem for us, but I'll take a look. I'm sure there are other cases. thanks /t