Re: fs tests failing

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

David Holland <dholland-current%netbsd.org@localhost> wrote:
>  > no, that's completely wrong.  ZFS's VOP_LOCK() currently doesn't
>  > actually lock anything, so having its VOP_ISLOCKED() say that it did
>  > is just crazy. all that does is defeat the assertions which are
>  > correctly pointing out that ZFS has a bug.
>  > 
>  > if you want to try to improve the situation, change all of the ZFS
>  > VOP_*LOCK* to use the genfs ones.  I don't know whether or not that
>  > will be sufficient, but it will at least be a step in the right
>  > direction.
> 
> ZFS has its own, completely different, and incompatible locking
> scheme, which is also incorrect (check out its rename...)

There is nothing fundamentally incorrect about ZFS locking.  There may be
bugs in rename, given its complexity, but the last time I looked - it did
more or less the same what we do now, except instead of a global lock (to
protect the tree of inodes), it actually walked down the path and locked
every inode in rather interesting way.

Anyway, you never bothered to demonstrate the actual problem with their
rename.  Care to write a test case for Solaris?

> The options are:
> 
> (1) rip out ZFS's locking scheme and replace it with a traditional one
> 
> (2) fix ZFS's locking scheme, teach VFS to interact with it
> 
> (3) let ZFS lie to the VFS code and hope it works

I agree that mixing different locking models is asking for trouble.

> both (1) and (2) are huge amounts of work with long-term consequences,
> so sticking to (3) until proven nonviable is by far the best
> short-term approach.
> 
> Also, given what I've seen so far of the ZFS locking, my guess is that
> (2) and (1) are in fact more or less the same thing.

No.  Many engineers already agreed on tech-kern@ that pushing locking
into the file systems, effectively replacing BSD-style VFS locking, is
a right way to go.  This and genfs (genfs_rename.c is already a step
to that direction) would solve many problems.

-- 
Mindaugas