RE: [nfsv4] lease renewal with delegreturn and delegpurge

cburnett@us.ibm.com

Subject: RE: [nfsv4] lease renewal with delegreturn and delegpurge
Message-ID: <OFBD7E9F10.73533A80-ON87256D21.0057DB00@us.ibm.com>
From: Carl Burnett <cburnett@us.ibm.com>
Date: Fri, 9 May 2003 11:00:51 -0500

Your suggested approaches seem reasonable.

Thanks Dave,
Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

"Noveck, Dave" <Dave.Noveck@netapp.com>
05/08/2003 04:40 PM

        To:     Carl Burnett/Austin/IBM@IBMUS, <nfsv4@ietf.org>
        cc: 
        Subject:        RE: [nfsv4] lease renewal with delegreturn and delegpurge

The only conclusion I'm prepared to draw is that no matter
how carefully you try to review the spec there will be found
for a very long time, maybe forever.  Ugh!

I guess that I probably would renew in this in case, since
it is explicitly mentioned.  On the other hand, in client 
renewal logic, I would not assume that the renewal had been
done.  If nothing else was going on to do renewal, I would
do an explict RENEW and not depend on DELEGPURGE.

If DELEGPURGE is not supported, I wouldn't think you had to do
renewal.  I see the argument but I would weasel out of it using
the phrase "operation is made".  In the case of a non-supported
operation, I would argue that the operation was merely requested,
but did not in fact occur.

As far as DELEGRETURN, I think BAD_STATEID would be the proper
error.  If the client gives you an inavlid stateid, then it is
clear.  If he gives you a valid stateid, which is not for a 
delegation, then the you should return the same error BAD_STATEID.
The fact there are no valid stateids for this purpose shouldn't
affect the fact that he must be giving you an invalid statedi
for the purpose.

-----Original Message-----
From: Carl Burnett [mailto:cburnett@us.ibm.com]
Sent: Thursday, May 08, 2003 5:11 PM
To: nfsv4@ietf.org
Subject: [nfsv4] lease renewal with delegreturn and delegpurge

>From the spec,
<<
   The following events cause implicit renewal of all of the leases for
   a given client (i.e., all those sharing a given clientid).  Each of
   these is a positive indication that the client is still active and
   that the associated state held at the server, for the client, is
   still valid.

   o  An OPEN with a valid clientid.

   o  Any operation made with a valid stateid (CLOSE, DELEGPURGE,
      DELEGRETURN, LOCK, LOCKU, OPEN, OPEN_CONFIRM, OPEN_DOWNGRADE,
      READ, RENEW, SETATTR, WRITE).  This does not include the special
      stateids of all bits 0 or all bits 1.
>>

DELEGPURGE  and RENEW take a clientid4, not a stateid. The purpose of 
RENEW is clear. Is it still correct to assume that DELEGPURGE should do 
lease renewal using the clientid?

If DELEGURGE is not supported, is it a correct assumption that it still 
must handle lease renewal for a valid clientid? 

For DELEGRETURN, if a client, in error, does a DELEGRETURN to a server 
that has never granted any delegations, what would the correct error be 
(NFS4ERR_INVAL??), and should the client's lease be renewed(my vote would 
be no)?

Thanks,
Carl

Carl Burnett
AIX Kernel Architecture - Distributed File Systems
(512) 838-8498, TL 678-8498
(please reply to cburnett@us.ibm.com)

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4