Subject: One last addition to NFSv4 I-D (extend WG last call)

From: Spencer Shepler <[email-masked]>
Date: Fri, 11 Feb 2000 12:48:11 -0600

Today is to be the close of the WG last call for
"NFS version 4 Protocol", draft-ietf-nfsv4-05.txt.
I would like to extend the last call to the close
of business on Tuesday, February 15th.

The reason for this request is that Dave Noveck has 
made a suggestion that there be a few additional 
comments added to the section on migration and 
replication.  This section lacks specific comments 
on the transfer of state information on migration 
and replication events.

I have drafted an addition to this section and it
is included below.  It seems reasonable to add something
to this section and hence the request to extend
the last call.

If there are objections to the timing of the last call
or comments on the content provided below, please
let me know.  Otherwise, we will move forward with the
new schedule and there will be a -nfsv4-06 draft that
will be the final product of the NFSv4 WG.

Thanks,
Spencer

----

6.5.  Transition of State

   When responsibility for handling a given file system is transferred
   to a new server (migration) or the client chooses to use an alternate
   server (e.g. in response to server unresponsiveness) in the context
   of file system replication, the appropriate handling of state shared
   between the client and server (i.e. locks, leases, stateid's, and
   clientid's) is as described below.  The handling differs between
   migration and replication.  For related discussion of file server
   state and recover of such see the sections under "File Locking and
   Share Reservations"

6.5.1.  Migration and State

   In the case of migration, the servers involved in the migration of a
   file system should transfer all server state from the original to the
   new server.  This must be done in a way that is transparent to the
   client.  This state transfer will ease the client's transition when a
   file system migration occurs.  If the servers are successful in
   transferring all state, the client will continue to use stateid's
   assigned by the original server.  Therefore the new server must
   recognized these stateid's as valid.  This holds true for the
   clientid as well.  Since responsibility for an entire file system is
   transferred with a migration event, there is no possibility that
   conflicts will arise on the new server as a result of the transfer of
   locks.

   As part of the transfer of information between servers, leases would
   be transferred as well.  The leases being transferred to the new
   server will typically have a different expiration time from those for
   the same client, previously on the new server.  To maintain the
   property that all leases on a given server for a given client expire
   at the same time, the server should advance the expiration time to
   the later of the leases being transferred or the leases already
   present.  This allows the client to maintain lease renewal of both
   classes without special effort.

   Although discouraged, the state information may not be transferred
   from the original to new server upon migration.  In this case, when
   the client presents state information from the original server, the
   client must be prepared to receive either NFS4ERR_STALE_CLIENTID or
   NFS4ERR_STALE_STATEID from the new server.  The client should then
   recover its state information as it normally would in response to a
   server failure.  The new server must take care to allow for the
   recovery of state information as it would in the event of server
   restart.

6.5.2.  Replication and State

   Since client switch-over in the case of replication is not under
   server control, the handling of state is different.  In this case,
   leases, stateid's and clientid's do not have validity across a
   transition from one server to another.  The client must re-establish
   its locks on the new server.  This can be compared to the re-
   establishment of locks by means of reclaim-type requests after a
   server reboot.  The difference is that the server has no provision to
   distinguish requests reclaiming locks from those obtaining new locks
   or to defer the latter.  Thus, a client re-establishing a lock on the
   new server (by means of a LOCK or OPEN request), may have the
   requests denied due to a conflicting lock.  Since replication is
   intended for read-only use of filesystems, such denial of locks
   should not pose large difficulties in practice.  When an attempt to
   re-establish a lock on a new server is denied, the client should
   treat the situation as if his original lock had been revoked.

---

From: "Noveck, Dave" <[email-masked]>
Date: Fri, 11 Feb 2000 13:04:02 -0800

>    classes without special effort.

There's is an issue that I didn't think about when I proposed this.

The problem with this is that it works if the client already has
leases on the new server and has a stream of renewal requests 
going to the new server anyway.  The problem is that if he doesn't,
no renewals get done until the client finds out that the transfer
has occurred.  The problem is that as things stand, he will only 
find out about it next time he uses a file on that filesystem, which
may be considerably later.  There needs to be a way for the client 
to find this out sooner.  I propose one below.

>    recovery of state information as it would in the event of server

When you have "discouraged" followed by "may not be transferred" it 
isn't clear at first whether tranferring or not transferring is being
discouraged.

The problem of the client not finding out soon enough is even more
troublesome, in this case since the grace period is likely to expire
before the client finds out that ne needs to do a reclaim.  This will
result in lost locks.

So here is what I propose to deal with this problem.  I'm not sure 
exactly where it goes.  It would make sense at the end of this new
section, except that it deals with matter that are really introduced
in chapter 8.  Maybe all of there sections belong at the end of 
chapter 8?  Anyway, here is the text:

In order for the client to schedule renewal of leases
relocated to the new server, it must find out about 
lease relocation, before those leases expire.  To
effect this, all operations which implicitly renew
leases for a client (i.e. OPEN, CLOSE, READ, WRITE,
RENEQ, LOCK, LOCKT, LOCKU), will return the error
NFS4ERR_LEASE_MOVED if responsiblity for any of the
leases to be renewed has been transferred to a new 
server.  This condition will continue until the client
recieves an NFS4ERR_MOVED error for an access to each
filesystem for which a lease has been moved to a new
server.

When a client receives an NFS4ERR_LEASE_MOVED error, it
should peform some operation, such as a RENEW, on each 
filesystem associated with the server in question.  When
it receives an NFS4ERR_MOVED error, it is able to obtain 
the new server information (through the fs_locations
attribute) and perform renewal of those leases on the new 
server.  If the server has not had state transferred to 
it transparently, it will receive either NFS4ERR_STALE_CLIENTID 
or NFS4ERR_STALE_STATEID from the new server, as described 
above, and can then recover state information as it does
in the event of server failure.