Re: fs tests failing

[David Holland <dholland-current%netbsd.org@localhost>]

On Sun, Sep 02, 2012 at 01:59:01PM +0100, Mindaugas Rasiukevicius 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.

Yes, there is a problem in rename. This has been pointed out before.
Much of the locking (most particularly the bottom-up locking order) is
structured to make rename possible; this is more or less inevitable.
However, it means that fixing it will likely require significant
changes.

 > Anyway, you never bothered to demonstrate the actual problem with their
 > rename.

I've explained it to you before, I think more than once. If you look
closely at it, you'll find it yourself: they try to use both tree
depth and znode(?) address for ordering, and of course that doesn't
actually produce a deterministic ordering and therefore doesn't work.

 > Care to write a test case for Solaris?

Running any of the existing rename-pounding tests should be sufficient.

 > > 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.

No argument there.

 > > 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.

As has been explained to you repeatedly, this is the wrong approach.

-- 
David A. Holland
dholland%netbsd.org@localhost