Subject: Lease renewal handling at fs migration

From: Spencer Shepler <[email-masked]>
Date: Mon, 14 Feb 2000 16:09:45 -0600

I have incorported Dave's comments from last Friday that
dealt with the renewal of leases when file systems migrate.
I have moved the migration/replication state discussions
to section 8.  The diffs are included below.

I will be sending in this last draft at the close of
business but if you have comments, please send them.

Spencer

----

8.13.  Migration, Replication and 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"                                                    |

8.13.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.                                        |

   The servers may choose not to transfer the state information upon      |
   migration.  However, this choice is discouraged.  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.                                                               |

8.13.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.          |

8.13.3.  Notification of Migrated Lease                                   |

   In the case of lease renewal, the client may not be submitting         |
   requests for a file system that has been migrated to another server.   |
   This can occur because of the implicit lease renewal mechanism.  The   |
   client renews leases for all file systems when submitting a request    |
   to any one file system at the server.                                  |

   In order for the client to schedule renewal of leases that may have    |
   been relocated to the new server, the client must find out about       |
   lease relocation before those leases expire.  To accomplish this, all  |
   operations which implicitly renew leases for a client (i.e. OPEN,      |
   CLOSE, READ, WRITE, RENEW, LOCK, LOCKT, LOCKU), will return the error  |
   NFS4ERR_LEASE_MOVED if responsibility for any of the leases to be      |
   renewed has been transferred to a new server.  This condition will     |
   continue until the client receives an NFS4ERR_MOVED error for an       |
   access to each file system for which a lease has been moved to a new   |
   server.                                                                |

   When a client receives an NFS4ERR_LEASE_MOVED error, it should         |
   perform some operation, such as a RENEW, on each file system           |
   associated with the server in question.  When the client receives an   |
   NFS4ERR_MOVED error, the client can follow the normal process 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.

12.  Error Definitions

...

   NFS4ERR_LEASE_MOVED   A lease being renewed is associated with a file  |
                         system that has been migrated to a new server.   |

18.  RPC definition file
...
           NFS4ERR_READDIR_NOSPC   = 10030,                               |
           NFS4ERR_LEASE_MOVED     = 10031                                |