Subject: [nfsv4] Writes and reply caching

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 3 Oct 2006 15:38:01 -0400

There was some discussion at the interim working group meeting of
whether sessions are needed for data servers doing a limited set of
operations, such as READ, WRITE, and particularly given that they do
nothing really nastily non-idempotent like RENAME, REMOVE.
 
Writes have always been considered non-idempotent and placed into reply
caches.  In a way this is kind of odd since writes actually are,
strictly speaking, idempotent.  That is, repeated execution of the same
write multiple times has the same effect as execution of that write
once.
 
Nevertheless, putting writes in the reply cache is necessary to avoid
data corruption, the issue of how exactly to define "idempotent"
notwithstanding.  Suppose I do  writes A, B, C and I don't get any
response.  So I reconnect to the server and re-issue writes A, B, C.
Now, the server has outstanding two instances of each of A, B, and C.
If we are unlucky, then we can have a situation in which we execute and
reply to the second A, B, and C while the first A, B, and C are still
waiting around in the file system for some resource.  The point now is
that the client believes his writes are done so he is free to do a
logically later write D that may overlap one or more of A, B, C.  If any
of those subsequently are executed for the second time, then what has
been written by D can be overwritten and thus corrupted.  
 
Note that for WRITE, although you may see a reply for the re-issued
request, you will not see one that comes from the reply cache.  This is
unlike the case of RENAME-twice, where the essence of the problem is
that that the client will see an erroneous response, and the solution is
to make sure that he sees the correct response.  In fact. with sessions,
you will work fine even if you mark the WRITE request as non-cached,
since the critical benefit you get from sessions is that each request is
only executed once and that is what is necessary to prevent corruption.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4