Re: [WTF] ... is going on with current->fs->{root,mnt} accesses in pohmelfs

[Evgeniy Polyakov]

On Thu, Feb 11, 2010 at 05:10:18PM +0000, Al Viro (viro@xxxxxxxxxxxxxxxxxx) wrote:
> > No, it happens with my lock held. It is not a lock, but kind of
> > IO delegation, i.e. it is not dropped when rename or other protected
> > operation completed. Instead another client sends request to grab it and
> > server asks current holder to drop cache, perform writeback or whatever
> > else is needed.
> 
> And should such a request come between return from ->rename() and call
> of d_move() that follows it?

We mark inode dirty (including parent) and it has to be written back thus
there will be no ack until writeback completed, which in turn messes
with i_mutex, so will be postponed until rename and d_move() completed.

> > It can be a problem though if d_move() is called outside of path
> > protected by the VFS dir operations like rename/created/unlink and so
> > on, i.e. on behalf of some entity in the kernel which decides to move
> > dentries on itself. In this case POHMELFS is not protected.
> 
> Not an issue; there's no such fs-independent callers.
> 
> Fundamentally, how do you deal with MOESI when the mapping from strings you
> are using as object IDs to actual objects can change as the result of
> operations?  What's more, operation on one object can change that mapping
> for a huge number of other objects (rename() close to fs root changing
> pathnames of all files anywhere in the subtree being moved).

MOESI is actually a crap in a clustered filesystem. It does not scale
well since number of messages grows exponentially with nodes and
interconnects. Plus without PAXOS it does not provide needed redundancy
level.

Basic idea currently is to delegate every operation and ask server if it
is allowed or not. Thus server-side locking must be serialized to that
level. I believe that i_mutex is enough there - its the only lock used
actually except in some helpers like d_path().

-- 
	Evgeniy Polyakov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/