Re: NFS Client patch

Trond Myklebust (trond.myklebust@fys.uio.no)
Tue, 10 Jul 2001 10:22:16 +0200


>>>>> " " == 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/