Date: Sun, 26 Aug 2007 12:29:43 -0400 From: Jan Harkes <jaharkes@coda.cs.cmu.edu> To: Nikolay Pavlov <qpadla@gmail.com> 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]) Message-ID: <20070826162943.GP28767@cs.cmu.edu> In-Reply-To: <200708251732.17394.qpadla@gmail.com> References: <200708202340.29678.qpadla@gmail.com> <20070824151927.GA11642@cs.cmu.edu> <200708251732.17394.qpadla@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070826162943.GP28767>