From owner-freebsd-current@FreeBSD.ORG Sun Aug 26 16:29:47 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CAEF16A475; Sun, 26 Aug 2007 16:29:47 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from delft.aura.cs.cmu.edu (unknown [IPv6:2002:8002:ce58::1]) by mx1.freebsd.org (Postfix) with ESMTP id C6D8413C468; Sun, 26 Aug 2007 16:29:46 +0000 (UTC) (envelope-from jaharkes@cs.cmu.edu) Received: from jaharkes by delft.aura.cs.cmu.edu with local (Exim 4.67) (envelope-from ) id 1IPKzf-0008DW-Hn; Sun, 26 Aug 2007 12:29:43 -0400 Date: Sun, 26 Aug 2007 12:29:43 -0400 From: Jan Harkes To: Nikolay Pavlov Message-ID: <20070826162943.GP28767@cs.cmu.edu> Mail-Followup-To: Nikolay Pavlov , freebsd-current@freebsd.org, rwatson@freebsd.org References: <200708202340.29678.qpadla@gmail.com> <20070824151927.GA11642@cs.cmu.edu> <200708251732.17394.qpadla@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200708251732.17394.qpadla@gmail.com> User-Agent: Mutt/1.5.16 (2007-06-11) Cc: freebsd-current@freebsd.org, rwatson@freebsd.org Subject: Re: And probably the final crash for today's current :) (panic: filesystem goof: vop_panic[vop_print]) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2007 16:29:47 -0000 On Sat, Aug 25, 2007 at 05:32:13PM +0300, Nikolay Pavlov wrote: > On Friday 24 August 2007 18:19:27 Jan Harkes wrote: > > The following patch adds locking around VOP_ operations. I ran some > > tests and it seems like I got them all. For some reason I could only get > > the warnings to go away when using exclusive locks, but since the > > overhead in our case really is in userspace and we still hold the giant > > lock pretty much everywhere there shouldn't be a measurable difference. > > With your patch everything works fine, but only if i'am using UFS as a > cachedir, rvm and checkpointdir backend. > If i'am using ZFS as a backend a panic occur with "ls -l /coda" command. Probably because the Coda client writes out directory data to the container files in BSD (UFS) format and then uses VOP_READDIR to read them. But ZFS expects a different layout of the directory data and as such VOP_READDIR won't work. In Linux we never could rely on being able to call the underlying fs readdir implementation, so the kernel module there already does it's own parsing of the directory entries in the container files and them one by one back to the VFS. So it is possible, but for now Coda's venus.cache subtree (the container files) just have to be stored on an UFS formatted partition. Jan