Re: NFS Client patch

[Andi Kleen <ak@suse.de>]

On Tue, Jul 10, 2001 at 12:48:20PM -0400, Craig Soules wrote:
> On Tue, 10 Jul 2001, Andi Kleen wrote:
> > Because to get that new cookie you would need another cookie; otherwise
> > you could violate the readdir guarantee that it'll never return files
> > twice.
> 
> I cannot locate any such guarantee in the NFS spec... are you refering to
> another spec which applies?

It's the unix semantics of readdir(); e.g. specified in Single Unix:

``   The type DIR, which is defined in the header <dirent.h>, represents
     a directory stream, which is an ordered sequence of all the
     directory entries in a particular directory. Directory entries
     represent files; files may be removed from a directory or added to
     a directory asynchronously to the operation of readdir(). ''

An ordered sequence does not include cycles.


> 
> > BTW; the cookie issue is not an NFS only problem. It occurs on local
> > IO as well. Just consider rm -rf - reading directories and in parallel
> > deleting them (the original poster's file system would have surely
> > gotten that wrong). Another tricky case is telldir().  
> 
> I don't believe that the behavior in this case is deterministic.  If you
> have multiple people accessing a single file, reading and writing to it,
> there is no guarantee as to what the behavior is.  The client should be
> able to handle any errors it creates for itself while doing this kind of
> parallel operation.

What happens with new entries added is unspecified; but old entries removed
in parallel should never cause a violation of the rule above.

A simple index into a rebalancing btree unfortunately doesn't fulfil this;
but there are ways to add additional layers to fix it.

The easiest test for it is rm -rf. 


-Andi