[lkml]   [2001]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS Client patch
>>>>> " " == Craig Soules <> 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...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:56    [W:0.059 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site