On Wed, Nov 27, 2002 at 09:25:35PM +0100, Trond Myklebust wrote:
> >>>>> " " == Stephen C Tweedie <sct@redhat.com> writes:
> > So I suspect that this is a root a client problem --- the
> > client has repeated a READDIR despite being told that the
> > previous reply was EOF
> I disagree. As far as the client is concerned, it has just been asked
> to read the entry that corresponds to that particular cookie.
No, it hasn't --- at least not unless there has been a seekdir in
between. If the client has already been told that we're at EOF, then
it's wrong to go back to the server again for more data.
Having said that, the server is clearly in error in sending a
duplicate cookie in the first place, and if it did so we'd never get
into such a state.
> If
> glibc issued a new readdir request (which is what I suspect has
> happened here), the NFS client has no idea what the previous reply
> was
Well, glibc will *always* issue another readdir, because the only way
we can ever tell glibc that we're at EOF on the directory is when we
eventually return 0 from getdents. The question about client
behaviour is, if we've already been told that the stream is at EOF,
should the client simply discard that info and keep reading
regardless, or should it cache the EOF status?
> IOW: A cookie should *always* be unique. There are no exceptions to
> this rule.
Agreed.
--Stephen
-
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/