Re: And probably the final crash for today's current :) (panic: filesystem goof: vop_panic[vop_print])

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