Subject: RE: close-retransmission issue (WAS RE: todo list for RFC3010)

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 24 May 2001 07:34:01 -0700

Mattew J. Zito wrote:
> As far as the close-retransmission issue goes, I think the server 
> should maintain the close information for a certain amount of time. 

But how long?  If you are talking about something on the order of
the lease time, there could be awful lot of closes that occur in
that window.  Are you saying that all of that information should
be retained?

> If there is a retransmission of the close() comamand after the 
> original was received, it should return an error. 

I don't understand this.  If there is a retransmission after the 
original was received, then if you do nothing special (to retain 
information on closed files) you will return an error 
(NFS4ERR_BAD_STATEID), but you don't want to return an error
in this case, you want to return success since the reply may
have been lost.  If the retransmission is something held by a 
router and disgorged after the reply was recieved (i.e. not a true
resend by the client), it doesn't matter what you return since
nobody is going to look at it.

> The only downside 
> to doing this is the server has to keep track of recently closed 
> files, but I think that's preferable to having an nfs server simply 
> return OKs regardless of whether or not it knows anything about that 
> request.

I think all the server has to do is keep track of one closed file
per lockowner.  As soon as it gets any other sequenced request for
that lockowner, the information can go away since we know the reply
was received, or else the next sequenced request would not be issued.

I've implemented this in my server.  It isn't that bad.  It's more
complicated than ignoring the issue and just saying there is no
error when you don't recognize a stateid, but it isn't terrible.

The only other thing is that you need to be able to get rid of
the close information some time, even if the lockowner does nothing
more.  This can be timed out, using the lease period.  Once the
server sees that a lockowner has no locks for a time (which must
be at least the lease period but probably will be considerably
longer), he can deallocate information about the lockowner including
the current sequence and any information about a closed file's
stateid.

I think the spec should say that a server SHOULD maintain that
information until the earliest of:

      Another validly sequenced request for the same lockowner,
      that is not a retransmission.

      The time that a lockowner is freed by the server due to 
      period with no activity.

      All locks for the client are freed as a result of a 
      SETCLIENTID.

It's a not a MUST so simple servers could just return no error
if it gets a close request and it doesn't recognize the stateid
(as long as it determines it is not a STALE_STATEID situation).

---

From: "Kendrick M. Smith" <[email-masked]>
Date: Thu, 24 May 2001 11:53:31 -0400 (EDT)

> the current sequence and any information about a closed file's

I agree; in fact this is the same scheme that I've implemented in the
Linux server.

- k