Re: NFS Client patch

[Trond Myklebust <trond.myklebust@fys.uio.no>]

>>>>> " " == Craig Soules <soules@happyplace.pdl.cmu.edu> writes:

     > On Mon, 9 Jul 2001, Trond Myklebust wrote:
    >> If the client discovers that the cache is invalid, it clears
    >> it, and refills the cache. We then start off at the next cookie
    >> after the last read cookie. Test it on an ordinary filesystem
    >> and you'll see the exact same behaviour. The act of creating or
    >> deleting files is *not* supposed invalidate the readdir offset.

     > I would say that assuming that the readdir cookie is an offset
     > is a break in the spec.  In fact, there are a few things in the
     > spec which I'd like to point out.  First of all, "All of the
     > procedures in the NFS protocol are assumed to be synchronous."
     > Which means that you should not even be making asynchronous
     > remove calls.  Second, the server is meant to be "as stateless
     > as possible."  I would argue that this means that you should
     > not make assumptions about the cookie's state if another
     > operation is interposed between two readdir() operations.  As
     > an aside, by adding a translation layer to the cookies (as
     > suggested by an earlier post) would break this, as the server
     > would have to store that state in the event of a server crash,
     > thus breaking the spec.

Imagine if somebody gives you a 1Gb directory. Would it or would it
not piss you off if your file pointer got reset to 0 every time
somebody created a file?

The current semantics are scalable. Anything which resets the file
pointer upon change of a file/directory/whatever isn't...

Cheers,
  Trond