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

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Spencer Shepler (shepler@eng.sun.com)
Date: 02/11/00-12:48:11 PM Z 

Message-ID: <38A4596B.E6A9828@eng.sun.com>
Date: Fri, 11 Feb 2000 12:48:11 -0600
From: Spencer Shepler <shepler@eng.sun.com>
Subject: One last addition to NFSv4 I-D (extend WG last call)


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.

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:48:04 AM Z CST