Messages in this thread | | | Date | Tue, 10 Jul 2001 10:22:16 +0200 | Subject | Re: NFS Client patch | From | Trond Myklebust <> |
| |
>>>>> " " == 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/
| |