This is write coalescing, not caching - the synchronous requirement
means the write-through cache has to put data to the stable store before
it returns. it is that simple - do not try to read more into it than that.
i could have a 100 write requests come in, and none of the writes can be
acknowledged until the data for that write is on stable store. that is what
the RFC says -
"When a procedure returns to the client, the client can
assume that the operation has completed and any data associated with
the request is now on stable storage."
remember this is with regards to write server-caching is not allowed in
NFSv2, read server-caching is fine.
> This is also part of NFSv2 for most commands: look up READ, WRITE,
> LOOKUP, CREATE, MKDIR, and most other commands. As for NFSv3, the main
> interest is that of speed and 64-bit filesizes; not security. Weak
> cache consistency idea gives you very little new information since you
> generally have no guarantee that your sunrpc requests are ordered when
> using UDP. Please see the NFSv3 patches for how we currently use that
> information...
>
i have no dispute how you handle client-side caching, it is not specified.
the only question you should worry about is the consistency guarantees of
your system. you need some extra measure to get strong consistency using
NFS.
> Cheers,
> Trond
I hope this clarifies,
Charles
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/