Re: [fuse-devel] concurrent write and read operations

[Miklos S. <mi...@sz...>]

> > If you rename a directory, the name won't become NULL, but the tree
> > can change.
> >
> > For example stat("/a/b/c/d") and rename("/a/b", "/e/f") is done in
> > parallel.  After collecting the nodes for the stat() the rename is
> > performed, so get_path() will return "/e/f/c/d", but we locked a, b,
> > instead of e and f, which is wrong.
> >   
> 
> I thought and implemented the following idea for this problem. After 
> locking the nodes, we would traverse each path to get the path name. Now 
> besides checking if the name still exists, we also check if the path 
> node is locked (ie, it makes part of our locked_nodes list) and if its 
> parent is the same as the one at the time we collected the nodes for 
> locking. That is done by storing also the parent information in the 
> struct locked_node_list. I think that it would cover the cases where 
> name becomes NULL, what is simpler than checking the locked_nodes, and 
> also those cases where:
> 
> a. a new node was added to the path, so it's unlocked
> b. an old node (thus locked) but had its hierarchy changed (parent is 
> not the same)
> 
> What do you think of this idea?

I *think* it should work, but I need to sleep on it.  You may not even
have to check the parent.  If every node in the path is locked, then
we should be OK.

One more problem is that if the verification fails, it shouldn't error
out, but retry locking the nodes.  It is not an error to have
concurrent operations going on.

Thanks,
Miklos