Subject: [nfsv4] Issue with reclaim open-upgrades

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 20 Jul 2007 13:35:00 -0400

The current spec has the following and I've been pondering what to do
about it as part of the rewrite of the locking chapters.

   Therefore, the client MUST NOT perform an OPEN reclaim that is also
   an OPEN upgrade (Section 8.10) unless the client precedes the OPEN
   upgrade/reclaim with a TEST_STATEID operation in the same COMPOUND.
   The stateid used in TEST_STATEID will be that returned by the reclaim
   OPEN the OPEN upgrade/reclaim is upgrading the open state from.
   Alternatively, the client can avoid OPEN upgrade during the reclaim
   phase.

It seems to me that this text is making an assumption that isn't really
valid and that each op of the COMPOUND will be executed during the same
reboot instance of the server.  It seems weird to say that that won't
happen but consider that we are dealing with persistent sessions and
there are counter-intuitive situations.

Consider a COMPOUND that has a rename of A to B and another op that
renames C to D.  Clearly the server can fail after one but before
executing the other.  What that means is that if the session is
persistent that COMPOUND is reissued then you will have a situation is
which reply cache provides the result, presumably OK for the first
rename and the second rename is not found in the reply cache, since it
wasn't executed in the earlier server instance.  So there we have a
clear case in which a COMPOUND contains ops executed in two different
reboot instances.

So given that that is possible in general, why isn't possible for the
TEST_STATEID above.  That is, why can you assume that because the
TEST_STATEID succeeded the open-upgrade-reclaim that follows is fact
going to be treated as an upgrade.  Couldn't the TEST_STATEID be take
from the reply cache and when the open is executed you are in a state in
which the stateid isn't valid.  So isn't the TEST_STATEID pointless?

So some ways to fix this:

     Simply don't allow open-upgrade on reclaim.  It doesn't
     seem like it is really necessary.

     Add some special rule about TEST_STATEID and persistent 
     sessions, which basically says that since they are 
     idempotent, they need not be saved, and must not be saved
     until some non-idempotent op has been processed (or just
     one more additional of any type), and then allow the 
     open-upgrade-reclaim if it is suitably close to the 
     TEST_STATEID.

     Change the sessions/recovery model to avoid this kind of 
     situation.  In particular, this issue seems to result from
     the fact that we force the clientid to be persistent, in 
     situation which state had been lost and you are then in a 
     situation in which it is hard for the server to know 
     exactly what operations are associated with what server 
     instance.  So I guess what I'm asking here is whether it
     would be better to avoid the situation in which you
     get reclaim-needed on an existing session and clientid
     and then proceed to do those reclaims.  Might it not be
     better to require heo client to establish a clientid and
     a new session for the reclaim.  He would have access to
     old session but primarily for the purpose of redoing
     COMPOUNDs that he hadn't got a reply to, i.e. to get the
     reply cache information saved persistently.

     Are there others?

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4