[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: fs tests failing
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
> Anyway, you never bothered to demonstrate the actual problem with their
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
Main Index |
Thread Index |