draft-ietf-nfsv4-rfc3530-migration-update-06.txt   draft-ietf-nfsv4-rfc3530-migration-update-07.txt 
NFSv4 D. Noveck, Ed. NFSv4 D. Noveck, Ed.
Internet-Draft Dell Internet-Draft HP
Updates: 3530bis (if approved) P. Shivam Updates: 7530 (if approved) P. Shivam
Intended status: Standards Track C. Lever Intended status: Standards Track C. Lever
Expires: July 8, 2015 B. Baker Expires: January 4, 2016 B. Baker
ORACLE ORACLE
January 4, 2015 July 3, 2015
NFSv4.0 migration: Specification Update NFSv4.0 migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-06 draft-ietf-nfsv4-rfc3530-migration-update-07
Abstract Abstract
The migration feature of NFSv4 allows for responsibility for a single The migration feature of NFSv4 allows for responsibility for a single
filesystem to move from one server to another, without disruption to filesystem to move from one server to another, without disruption to
clients. Recent implementation experience has shown problems in the clients. Recent implementation experience has shown problems in the
existing specification for this feature in NFSv4.0. This document existing specification for this feature in NFSv4.0. This document
clarifies and corrects RFC3530bis (the NFSv4.0 specification) to clarifies and corrects RFC7530 (the NFSv4.0 specification) to address
address these problems. these problems.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2015. This Internet-Draft will expire on January 4, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 17
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Client Identity Definition . . . . . . . . . . . . . . . . . 5 4. Client Identity Definition . . . . . . . . . . . . . . . . . 5
4.1. Differences from Replaced Sections . . . . . . . . . . . 5 4.1. Differences from Replaced Sections . . . . . . . . . . . 5
4.2. Client Identity Data Items . . . . . . . . . . . . . . . 5 4.2. Client Identity Data Items . . . . . . . . . . . . . . . 5
4.3. Server Release of Client ID . . . . . . . . . . . . . . . 10 4.3. Server Release of Client ID . . . . . . . . . . . . . . . 9
4.4. Client Id String Approaches . . . . . . . . . . . . . . . 10 4.4. Client Id String Approaches . . . . . . . . . . . . . . . 10
4.5. Non-Uniform Client Id String Approach . . . . . . . . . . 12 4.5. Non-Uniform Client Id String Approach . . . . . . . . . . 12
4.6. Uniform Client Id String Approach . . . . . . . . . . . . 13 4.6. Uniform Client Id String Approach . . . . . . . . . . . . 13
4.7. Mixing Client Id String Approaches . . . . . . . . . . . 15 4.7. Mixing Client Id String Approaches . . . . . . . . . . . 14
4.8. Trunking Determination when Using Uniform Client Id 4.8. Trunking Determination when Using Uniform Client Id
Strings . . . . . . . . . . . . . . . . . . . . . . . . . 16 Strings . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. Client Id String Construction Details . . . . . . . . . . 22 4.9. Client Id String Construction Details . . . . . . . . . . 22
5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23 5. Locking and Multi-Server Namespace . . . . . . . . . . . . . 23
5.1. Changes from Replaced Sections . . . . . . . . . . . . . 23 5.1. Lock State and Filesystem Transitions . . . . . . . . . . 24
5.2. Lock State and Filesystem Transitions . . . . . . . . . . 24 5.1.1. Migration and State . . . . . . . . . . . . . . . . . 24
5.3. Migration and State . . . . . . . . . . . . . . . . . . . 24 5.1.1.1. Migration and Clientid's . . . . . . . . . . . . 26
5.3.1. Migration and Clientid's . . . . . . . . . . . . . . 26 5.1.1.2. Migration and State Owner Information . . . . . . 27
5.3.2. Migration and State Owner Information . . . . . . . . 27 5.1.2. Replication and State . . . . . . . . . . . . . . . . 31
5.4. Replication and State . . . . . . . . . . . . . . . . . . 31 5.1.3. Notification of Migrated Lease . . . . . . . . . . . 31
5.5. Notification of Migrated Lease . . . . . . . . . . . . . 31 5.1.4. Migration and the Lease_time Attribute . . . . . . . 33
5.6. Migration and the Lease_time Attribute . . . . . . . . . 34
6. Server Implementation Considerations . . . . . . . . . . . . 34 6. Server Implementation Considerations . . . . . . . . . . . . 34
6.1. Relation of Locking State Transfer to Other Aspects of 6.1. Relation of Locking State Transfer to Other Aspects of
Filesystem Motion . . . . . . . . . . . . . . . . . . . . 34 Filesystem Motion . . . . . . . . . . . . . . . . . . . . 34
6.2. Preventing Locking State Modification During Transfer . . 36 6.2. Preventing Locking State Modification During Transfer . . 36
7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39 7. Additional Changes . . . . . . . . . . . . . . . . . . . . . 39
7.1. Summary of Additional Changes from Previous Documents . . 39 7.1. Summary of Additional Changes from Previous Documents . . 39
7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40 7.2. NFS4ERR_CLID_INUSE definition . . . . . . . . . . . . . . 40
7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40 7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER . . . . . . . 40
7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41 7.4. Operation 35: SETCLIENTID - Negotiate Client ID . . . . . 41
7.5. Security Considerations for Inter-server Information 7.5. Security Considerations for Inter-server Information
Transfer . . . . . . . . . . . . . . . . . . . . . . . . 45 Transfer . . . . . . . . . . . . . . . . . . . . . . . . 45
7.6. Security Considerations Revision . . . . . . . . . . . . 45 7.6. Security Considerations Revision . . . . . . . . . . . . 45
8. Security Considerations . . . . . . . . . . . . . . . . . . . 46 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 46
10.1. Normative References . . . . . . . . . . . . . . . . . . 46 10.1. Normative References . . . . . . . . . . . . . . . . . . 46
10.2. Informative References . . . . . . . . . . . . . . . . . 46 10.2. Informative References . . . . . . . . . . . . . . . . . 46
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 46
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
This document is a standards track document which corrects the This document is a standards track document which corrects the
existing definitive specification of the NFSv4.0 protocol, in existing definitive specification of the NFSv4.0 protocol, in
[RFC3530bis]. Given this fact, one should take the current document [RFC7530]. Given this fact, one should take the current document
into account when learning about NFSv4.0, particularly if one is into account when learning about NFSv4.0, particularly if one is
concerned with issues that relate to: concerned with issues that relate to:
o Filesystem migration, particularly when it involves transparent o Filesystem migration, particularly when it involves transparent
state migration. state migration.
o The construction and interpretation of the nfs_clientid4 structure o The construction and interpretation of the nfs_clientid4 structure
and particularly the requirements on the id string within it, and particularly the requirements on the id string within it,
referred to below as a "client id string". referred to below as a "client id string".
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Background 3. Background
Implementation experience with transparent state migration has Implementation experience with transparent state migration has
exposed a number of problems with the then-existing specifications of exposed a number of problems with the then-existing specifications of
this feature, in [RFC3530bis] and predecessors. The symptoms were: this feature, in [RFC7530] and predecessors. The symptoms were:
o After migration of a filesystem, a reboot of the associated client o After migration of a filesystem, a reboot of the associated client
was not appropriately dealt with, in that the state associated was not appropriately dealt with, in that the state associated
with the rebooting client was not promptly freed. with the rebooting client was not promptly freed.
o Situations can arise whereby a given server has multiple leases o Situations can arise whereby a given server has multiple leases
with the same nfs_client_id4 (id and verifier), when the protocol with the same nfs_client_id4 (id and verifier), when the protocol
clearly assumes there can be only one. clearly assumes there can be only one.
o Excessive client implementation complexity since clients have to o Excessive client implementation complexity since clients have to
skipping to change at page 4, line 15 skipping to change at page 4, line 13
existing client definition structures on the destination server. existing client definition structures on the destination server.
Specification of requirements for the server to appropriately merge Specification of requirements for the server to appropriately merge
stateids associated with a common client boot instance encounters a stateids associated with a common client boot instance encounters a
difficult problem. The issue is that the common client practice with difficult problem. The issue is that the common client practice with
regard to the presentation of unique strings specifying client regard to the presentation of unique strings specifying client
identity makes it essentially impossible for the client to determine identity makes it essentially impossible for the client to determine
whether or not two stateids, originally generated on different whether or not two stateids, originally generated on different
servers are referable to the same client. This practice is allowed servers are referable to the same client. This practice is allowed
and endorsed, although not "RECOMMENDED", by the existing NFSv4.0 and endorsed, although not "RECOMMENDED", by the existing NFSv4.0
specification, [RFC3530bis]). specification ([RFC7530]).
To further complicate matters, upon prototyping of clients To further complicate matters, upon prototyping of clients
implementing an alternative approach, it has been found that there implementing an alternative approach, it has been found that there
exist servers which do not work well with these new clients. It exist servers which do not work well with these new clients. It
appears that current circumstances, in which a particular client appears that current circumstances, in which a particular client
implementation pattern had been adopted universally, has resulted in implementation pattern had been adopted universally, has resulted in
servers not being able to interoperate against alternate client servers not being able to interoperate against alternate client
implementation patterns. As a result, we have a situation which implementation patterns. As a result, we have a situation which
requires careful attention to compatibility issues to untangle. requires careful attention to compatibility issues to untangle.
This document updates the existing NFSv4.0 specification This document updates the existing NFSv4.0 specification ([RFC7530])
[RFC3530bis]) as follows: as follows:
o It makes clear that NFSv4.0 supports multiple approaches to the o It makes clear that NFSv4.0 supports multiple approaches to the
construction of client id strings, including that formerly construction of client id strings, including that formerly
endorsed by existing NFSV4.0 specifications, and currently widely endorsed by existing NFSV4.0 specifications, and currently widely
deployed. deployed.
o It addresses the potential compatibility issues that might arise o It addresses the potential compatibility issues that might arise
for clients adopting a previously non-favored client id for clients adopting a previously non-favored client id
construction approach including the existence of servers which construction approach including the existence of servers which
have problems with the new approach. have problems with the new approach.
skipping to change at page 5, line 13 skipping to change at page 5, line 11
where the specification text does not take proper account of the where the specification text does not take proper account of the
issues raised by state migration or where it has been found that issues raised by state migration or where it has been found that
the existing text is insufficiently clear. the existing text is insufficiently clear.
For a more complete explanation of the choices made in addressing For a more complete explanation of the choices made in addressing
these issues, see [info-migr]). these issues, see [info-migr]).
4. Client Identity Definition 4. Client Identity Definition
This chapter is a replacement for sections 9.1.1 and 9.1.2 in This chapter is a replacement for sections 9.1.1 and 9.1.2 in
[RFC3530bis]). The replaced sections are named "client ID" and [RFC7530]. The replaced sections are named "client ID" and "Server
"Server Release of Clientid." Release of Clientid."
It supersedes the replaced sections. It supersedes the replaced sections.
4.1. Differences from Replaced Sections 4.1. Differences from Replaced Sections
Because of the need for greater attention to and careful description Because of the need for greater attention to and careful description
of this area, this chapter is much larger than the sections it of this area, this chapter is much larger than the sections it
replaces. The principal changes/additions made by this chapter are: replaces. The principal changes/additions made by this chapter are:
o It corrects inconsistencies regarding the possible role or non- o It corrects inconsistencies regarding the possible role or non-
skipping to change at page 9, line 37 skipping to change at page 9, line 31
In the event of a server reboot, loss of lease state due to lease In the event of a server reboot, loss of lease state due to lease
expiration, or administrative revocation of a clientid4, the client expiration, or administrative revocation of a clientid4, the client
must obtain a new clientid4 by use of the SETCLIENTID operation and must obtain a new clientid4 by use of the SETCLIENTID operation and
then proceed to any other necessary recovery for the server reboot then proceed to any other necessary recovery for the server reboot
case (See the section entitled "Server Failure and Recovery"). In case (See the section entitled "Server Failure and Recovery"). In
cases of server or client error resulting in this error, use of cases of server or client error resulting in this error, use of
SETCLIENTID to establish a new lease is desirable as well. SETCLIENTID to establish a new lease is desirable as well.
In the last two cases, different recovery procedures are required. In the last two cases, different recovery procedures are required.
See Section 5.3 for details. Note that in cases in which there is See Section 5.1.1 for details. Note that in cases in which there is
any uncertainty about which sort of handling is applicable, the any uncertainty about which sort of handling is applicable, the
distinguishing characteristic is that in reboot-like cases, the distinguishing characteristic is that in reboot-like cases, the
clientid4 and all associated stateids cease to exist while in clientid4 and all associated stateids cease to exist while in
migration-related cases, the clientid4 ceases to exist while the migration-related cases, the clientid4 ceases to exist while the
stateids are still valid. stateids are still valid.
The client must also employ the SETCLIENTID operation when it The client must also employ the SETCLIENTID operation when it
receives a NFS4ERR_STALE_STATEID error using a stateid derived from receives a NFS4ERR_STALE_STATEID error using a stateid derived from
its current clientid4, since this indicates a situation, such as its current clientid4, since this indicates a situation, such as
server reboot which has invalidated the existing clientid4 and server reboot which has invalidated the existing clientid4 and
skipping to change at page 13, line 45 skipping to change at page 13, line 41
difference in behavior allows the client to infer the server IP difference in behavior allows the client to infer the server IP
address trunking configuration, even though NFSv4.0 does not address trunking configuration, even though NFSv4.0 does not
explicitly provide this information. explicitly provide this information.
The approach given in the section below shows one example of how The approach given in the section below shows one example of how
this might be done. this might be done.
The uniform client id string approach makes it necessary to exercise The uniform client id string approach makes it necessary to exercise
more care in the definition of the nfs_client_id4 boot verifier: more care in the definition of the nfs_client_id4 boot verifier:
o In [RFC3530bis], the client is told to change the boot verifier o In [RFC7530], the client is told to change the boot verifier when
when reboot occurs, but there is no explicit statement as to the reboot occurs, but there is no explicit statement as to the
converse, so that any requirement to keep the verifier constant converse, so that any requirement to keep the verifier constant
unless rebooting is only present by implication. unless rebooting is only present by implication.
o Many existing clients change the boot verifier every time they o Many existing clients change the boot verifier every time they
destroy and recreate the data structure that tracks an <IP- destroy and recreate the data structure that tracks an <IP-
address, clientid4> pair. This might happen if the last mount of address, clientid4> pair. This might happen if the last mount of
a particular server is removed, and then a fresh mount is created. a particular server is removed, and then a fresh mount is created.
Also, note that this might result in each <IP-address, clientid4> Also, note that this might result in each <IP-address, clientid4>
pair having its own boot verifier that is independent of the pair having its own boot verifier that is independent of the
others. others.
skipping to change at page 15, line 23 skipping to change at page 15, line 16
o Some existing NFSv4.0 server implementations of IP address o Some existing NFSv4.0 server implementations of IP address
failover depend on clients' use of a non-uniform client id string failover depend on clients' use of a non-uniform client id string
approach. In particular, when a server supports both its own IP approach. In particular, when a server supports both its own IP
address and one failed over from a partner server, it may have address and one failed over from a partner server, it may have
separate sets of state applicable to the two IP addresses, owned separate sets of state applicable to the two IP addresses, owned
by different servers but residing on a single one. by different servers but residing on a single one.
In this situation, some servers have relied on clients' use of the In this situation, some servers have relied on clients' use of the
non-uniform client id string approach, as suggested but not non-uniform client id string approach, as suggested but not
mandated by [RFC3530bis], to keep these sets of state separate, mandated by [RFC7530], to keep these sets of state separate, and
and will have problems in handling clients using the uniform will have problems in handling clients using the uniform client id
client id string approach, in that such clients will see changes string approach, in that such clients will see changes in trunking
in trunking relationships whenever server failover and giveback relationships whenever server failover and giveback occur.
occur.
o Some existing servers incorrectly return NFS4ERR_CLID_INUSE simply o Some existing servers incorrectly return NFS4ERR_CLID_INUSE simply
because there already exists a clientid for the same client, because there already exists a clientid for the same client,
established using a different IP address. This causes difficulty established using a different IP address. This causes difficulty
for a multi-homed client using the uniform client id string for a multi-homed client using the uniform client id string
approach. approach.
Although this behavior is not correct, such servers still exist Although this behavior is not correct, such servers still exist
and the spec should give clients guidance about dealing with the and the spec should give clients guidance about dealing with the
situation, as well as making the correct behavior clear. situation, as well as making the correct behavior clear.
skipping to change at page 23, line 35 skipping to change at page 23, line 29
* The timestamp of when the NFSv4 software was first installed on * The timestamp of when the NFSv4 software was first installed on
the client (though this is subject to the previously mentioned the client (though this is subject to the previously mentioned
caution about using information that is stored in a file, caution about using information that is stored in a file,
because the file might only be accessible over NFSv4). because the file might only be accessible over NFSv4).
* A true random number, generally established once and saved. * A true random number, generally established once and saved.
5. Locking and Multi-Server Namespace 5. Locking and Multi-Server Namespace
This chapter is a replacement for section 7.7.6, "Lock State and File This chapter contains a replacement for section 9.14, "Migration,
System transitions", in [RFC3530bis]). Replication, and State", in [RFC7530].
It supersedes the replaced sections.
5.1. Changes from Replaced Sections The replacement is in Section 5.1 and supersedes the replaced
section.
These changes can be briefly summarized as follows: The changes made can be briefly summarized as follows:
o Adding text to address the case of stateid conflict on migration. o Adding text to address the case of stateid conflict on migration.
o Specifying that when leases are moved, as a result of filesystem o Specifying that when leases are moved, as a result of filesystem
migration, they are to be merged with leases on the destination migration, they are to be merged with leases on the destination
server that are connected to the same client. server that are connected to the same client.
o Adding text that deals with the case of a clientid4 being changed o Adding text that deals with the case of a clientid4 being changed
on state transfer as a result of conflict with an existing on state transfer as a result of conflict with an existing
clientid4. clientid4.
o Adding a section describing how information associated with o Adding a section describing how information associated with
openowners and lockowners is to be managed with regard to openowners and lockowners is to be managed with regard to
migration. migration.
o The description of handling of the NFS4ERR_LEASE_MOVED has been o The description of handling of the NFS4ERR_LEASE_MOVED has been
rewritten for greater clarity. rewritten for greater clarity.
5.2. Lock State and Filesystem Transitions 5.1. Lock State and Filesystem Transitions
When responsibility for handling a given filesystem is transferred to When responsibility for handling a given filesystem is transferred to
a new server (migration) or the client chooses to use an alternate a new server (migration) or the client chooses to use an alternate
server (e.g., in response to server unresponsiveness) in the context server (e.g., in response to server unresponsiveness) in the context
of filesystem replication, the appropriate handling of state shared of filesystem replication, the appropriate handling of state shared
between the client and server (i.e., locks, leases, stateids, and between the client and server (i.e., locks, leases, stateids, and
client IDs) is as described below. The handling differs between client IDs) is as described below. The handling differs between
migration and replication. migration and replication.
If a server replica or a server immigrating a filesystem agrees to, If a server replica or a server immigrating a filesystem agrees to,
or is expected to, accept opaque values from the client that or is expected to, accept opaque values from the client that
originated from another server, then it is a wise implementation originated from another server, then it is a wise implementation
practice for the servers to encode the "opaque" values in network practice for the servers to encode the "opaque" values in network
byte order. When doing so, servers acting as replicas or immigrating byte order. When doing so, servers acting as replicas or immigrating
filesystems will be able to parse values like stateids, directory filesystems will be able to parse values like stateids, directory
cookies, filehandles, etc. even if their native byte order is cookies, filehandles, etc. even if their native byte order is
different from that of other servers cooperating in the replication different from that of other servers cooperating in the replication
and migration of the filesystem. and migration of the filesystem.
5.3. Migration and State 5.1.1. Migration and State
In the case of migration, the servers involved in the migration of a In the case of migration, the servers involved in the migration of a
filesystem SHOULD transfer all server state associated with the filesystem SHOULD transfer all server state associated with the
migrating filesystem from source to the destination server. This migrating filesystem from source to the destination server. This
must be done in a way that is transparent to the client. This state must be done in a way that is transparent to the client. This state
transfer will ease the client's transition when a filesystem transfer will ease the client's transition when a filesystem
migration occurs. If the servers are successful in transferring all migration occurs. If the servers are successful in transferring all
state, the client will continue to use stateids assigned by the state, the client will continue to use stateids assigned by the
original server. Therefore the new server must recognize these original server. Therefore the new server must recognize these
stateids as valid and treat them as representing the same locks as stateids as valid and treat them as representing the same locks as
skipping to change at page 26, line 11 skipping to change at page 26, line 5
it normally would in response to a server failure. The new server 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 must take care to allow for the recovery of state information as it
would in the event of server restart. would in the event of server restart.
In those situations in which state has not been transferred, as shown In those situations in which state has not been transferred, as shown
by a return of NFS4ERR_BAD_STATEID, the client may attempt to reclaim by a return of NFS4ERR_BAD_STATEID, the client may attempt to reclaim
locks in order to take advantage of cases in which the destination locks in order to take advantage of cases in which the destination
server has set up a file-system-specific grace period in support of server has set up a file-system-specific grace period in support of
the migration. the migration.
5.3.1. Migration and Clientid's 5.1.1.1. Migration and Clientid's
Handling of clientid values is similar to that for stateids. Handling of clientid values is similar to that for stateids.
However, there are some differences that derive from the fact that a However, there are some differences that derive from the fact that a
clientid is an object which spans multiple filesystems while a clientid is an object which spans multiple filesystems while a
stateid is inherently limited to a single filesystem. stateid is inherently limited to a single filesystem.
The clientid4 and nfs_client_id4 information (id string and boot The clientid4 and nfs_client_id4 information (id string and boot
verifier) will be transferred with the rest of the state information verifier) will be transferred with the rest of the state information
and the destination server should use that information to determine and the destination server should use that information to determine
appropriate clientid4 handling. Although the destination server may appropriate clientid4 handling. Although the destination server may
skipping to change at page 27, line 16 skipping to change at page 27, line 12
to an inability to recall delegations. The client can determine the to an inability to recall delegations. The client can determine the
new clientid (the value c) from the response to SETCLIENTID. new clientid (the value c) from the response to SETCLIENTID.
The client can use its own information about leases with the The client can use its own information about leases with the
destination server to see if lease merger should have happened. When destination server to see if lease merger should have happened. When
there is any ambiguity, the client MAY use the above procedure to set there is any ambiguity, the client MAY use the above procedure to set
the proper callback information and find out, as part of the process, the proper callback information and find out, as part of the process,
the correct value of its clientid with respect to the server in the correct value of its clientid with respect to the server in
question. question.
5.3.2. Migration and State Owner Information 5.1.1.2. Migration and State Owner Information
In addition to stateids, the locks they represent, and clientid In addition to stateids, the locks they represent, and clientid
information, servers also need to transfer information related to the information, servers also need to transfer information related to the
current status of openowners and lockowners. current status of openowners and lockowners.
This information includes: This information includes:
o The sequence number of the last operation associated with the o The sequence number of the last operation associated with the
particular owner. particular owner.
skipping to change at page 31, line 7 skipping to change at page 31, line 5
o The server SHOULD drop the part of this information that relates o The server SHOULD drop the part of this information that relates
to non-migrated filesystems, if it receives a new sequence value to non-migrated filesystems, if it receives a new sequence value
for the owner in question and the request relates to a non- for the owner in question and the request relates to a non-
migrated filesystem. migrated filesystem.
o The server MAY drop this information when it receives a new o The server MAY drop this information when it receives a new
sequence value for the owner in question a considerable period of sequence value for the owner in question a considerable period of
time (more than one or two lease periods) after the migration time (more than one or two lease periods) after the migration
occurs. occurs.
5.4. Replication and State 5.1.2. Replication and State
Since client switch-over in the case of replication is not under Since client switch-over in the case of replication is not under
server control, the handling of state is different. In this case, server control, the handling of state is different. In this case,
leases, stateids and client IDs do not have validity across a leases, stateids and client IDs do not have validity across a
transition from one server to another. The client must re-establish transition from one server to another. The client must re-establish
its locks on the new server. This can be compared to the re- its locks on the new server. This can be compared to the re-
establishment of locks by means of reclaim-type requests after a establishment of locks by means of reclaim-type requests after a
server reboot. The difference is that the server has no provision to server reboot. The difference is that the server has no provision to
distinguish requests reclaiming locks from those obtaining new locks distinguish requests reclaiming locks from those obtaining new locks
or to defer the latter. Thus, a client re-establishing a lock on the 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 new server (by means of a LOCK or OPEN request), may have the
requests denied due to a conflicting lock. Since replication is requests denied due to a conflicting lock. Since replication is
intended for read-only use of filesystems, such denial of locks intended for read-only use of filesystems, such denial of locks
should not pose large difficulties in practice. When an attempt to should not pose large difficulties in practice. When an attempt to
re-establish a lock on a new server is denied, the client should re-establish a lock on a new server is denied, the client should
treat the situation as if its original lock had been revoked. treat the situation as if its original lock had been revoked.
5.5. Notification of Migrated Lease 5.1.3. Notification of Migrated Lease
A filesystem can be migrated to another server while a client that A filesystem can be migrated to another server while a client that
has state related to that filesystem is not actively submitting has state related to that filesystem is not actively submitting
requests to it. In this case, the migration is reported to the requests to it. In this case, the migration is reported to the
client during lease renewal. Lease renewal can occur either client during lease renewal. Lease renewal can occur either
explicitly via a RENEW operation, or implicitly when the client explicitly via a RENEW operation, or implicitly when the client
performs a lease-renewing operation on another filesystem on that performs a lease-renewing operation on another filesystem on that
server. server.
In order for the client to schedule renewal of leases that may have In order for the client to schedule renewal of leases that may have
skipping to change at page 34, line 5 skipping to change at page 33, line 48
simple as a GETFH operation. simple as a GETFH operation.
Though unlikely, it is possible that the target of such a compound Though unlikely, it is possible that the target of such a compound
could be migrated in the time after the guard operation is executed could be migrated in the time after the guard operation is executed
on the server but before the GETATTR(fs_locations) operation is on the server but before the GETATTR(fs_locations) operation is
encountered. When a client issues a GETATTR(fs_locations) operation encountered. When a client issues a GETATTR(fs_locations) operation
as part of a compound not intended to signal recognition of a as part of a compound not intended to signal recognition of a
migrated lease, it SHOULD be prepared to process fs_locations data in migrated lease, it SHOULD be prepared to process fs_locations data in
the reply that shows the current location of the filesystem is gone. the reply that shows the current location of the filesystem is gone.
5.6. Migration and the Lease_time Attribute 5.1.4. Migration and the Lease_time Attribute
In order that the client may appropriately manage its leases in the In order that the client may appropriately manage its leases in the
case of migration, the destination server must establish proper case of migration, the destination server must establish proper
values for the lease_time attribute. values for the lease_time attribute.
When state is transferred transparently, that state should include When state is transferred transparently, that state should include
the correct value of the lease_time attribute. The lease_time the correct value of the lease_time attribute. The lease_time
attribute on the destination server must never be less than that on attribute on the destination server must never be less than that on
the source since this would result in premature expiration of leases the source since this would result in premature expiration of leases
granted by the source server. Upon migration in which state is granted by the source server. Upon migration in which state is
skipping to change at page 40, line 30 skipping to change at page 40, line 25
7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER 7.3. NFS4ERR_DELAY return from RELEASE_LOCKOWNER
The existing error tables should be considered modified to allow The existing error tables should be considered modified to allow
NFS4ERR_DELAY to be returned by RELEASE_LOCKOWNER. However, the NFS4ERR_DELAY to be returned by RELEASE_LOCKOWNER. However, the
scope of this addition is limited and is not to be considered as scope of this addition is limited and is not to be considered as
making this error return generally acceptable. making this error return generally acceptable.
It needs to be made clear that servers may not return this error to It needs to be made clear that servers may not return this error to
clients not prepared to support filesystem migration. Such clients clients not prepared to support filesystem migration. Such clients
may be following the error specifications in [RFC3530bis] and so may be following the error specifications in [RFC7530] and so might
might not expect NFS4ERR_DELAY to be returned on RELEASE_LOCKOWNER. not expect NFS4ERR_DELAY to be returned on RELEASE_LOCKOWNER.
The following constraint applies to this additional error return, as The following constraint applies to this additional error return, as
if it were a note appearing together with the newly allowed error if it were a note appearing together with the newly allowed error
code: code:
In order to make server state fixed for a filesystem being In order to make server state fixed for a filesystem being
migrated, a server MAY return NFS4ERR_DELAY in response to a migrated, a server MAY return NFS4ERR_DELAY in response to a
RELEASE_LOCKOWNER that will affect locking state being propagated RELEASE_LOCKOWNER that will affect locking state being propagated
to a destination server. The source server MUST NOT do so unless to a destination server. The source server MUST NOT do so unless
it is likely that it will later return NFS4ERR_MOVED for the it is likely that it will later return NFS4ERR_MOVED for the
skipping to change at page 46, line 22 skipping to change at page 46, line 16
This document does not require actions by IANA. This document does not require actions by IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3530bis] [RFC7530] Haynes, T. and D. Noveck, "Network File System (NFS)
Haynes, T., Ed. and D. Noveck, Ed., "Network File System Version 4 Protocol", RFC 7530, March 2015.
(NFS) Version 4 Protocol", December 2014,
<http://www.ietf.org/id/
draft-ietf-nfsv4-rfc3530bis-35.txt>.
Work in progress.
10.2. Informative References 10.2. Informative References
[info-migr]
Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4 migration: Implementation experience and spec
issues to resolve", March 2015, <http://www.ietf.org/id/
draft-ietf-nfsv4-migration-issues-07.txt>.
Work in progress.
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS [RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995. Version 3 Protocol Specification", RFC 1813, June 1995.
[RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File [RFC5661] Shepler, S., Eisler, M., and D. Noveck, "Network File
System (NFS) Version 4 Minor Version 1 Protocol", RFC System (NFS) Version 4 Minor Version 1 Protocol", RFC
5661, January 2010. 5661, January 2010.
[info-migr]
Noveck, D., Ed., Shivam, P., Lever, C., and B. Baker,
"NFSv4 migration: Implementation experience and spec
issues to resolve", september 2014,
<http://www.ietf.org/id/
draft-ietf-nfsv4-migration-issues-06.txt>.
Work in progress.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The editor and authors of this document gratefully acknowledge the The editor and authors of this document gratefully acknowledge the
contributions of Trond Myklebust of Primary Data and Robert Thurlow contributions of Trond Myklebust of Primary Data and Robert Thurlow
of Oracle. We also thank Tom Haynes of Primary Data and Spencer of Oracle. We also thank Tom Haynes of Primary Data and Spencer
Shepler of Microsoft for their guidance and suggestions. Shepler of Microsoft for their guidance and suggestions.
Special thanks go to members of the Oracle Solaris NFS team, Special thanks go to members of the Oracle Solaris NFS team,
especially Rick Mesta and James Wahlig, for their work implementing especially Rick Mesta and James Wahlig, for their work implementing
an NFSv4.0 migration prototype and identifying many of the issues an NFSv4.0 migration prototype and identifying many of the issues
addressed here. addressed here.
Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this
document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFC3530bis with RFCxxxx where xxxx is the
RFC number assigned to that dpcument.]
[RFC Editor: prior to publishing this document as an RFC, please
change the specfication of the document that this document updates
from "3530bis" to xxxx where xxxx is the RFC number assigned to
RFC3530bis.
Authors' Addresses Authors' Addresses
David Noveck (editor) David Noveck (editor)
Dell Hewlett-Packard
300 Innovative Way 165 Dascomb Road
Nashua, NH 03062 Andover, MA 01810
US US
Phone: +1 781 572 8038 Phone: +1 978 474 2011
Email: dave_noveck@dell.com Email: davenoveck@gmail.com
Piyush Shivam Piyush Shivam
Oracle Corporation Oracle Corporation
5300 Riata Park Ct. 5300 Riata Park Ct.
Austin, TX 78727 Austin, TX 78727
US US
Phone: +1 512 401 1019 Phone: +1 512 401 1019
Email: piyush.shivam@oracle.com Email: piyush.shivam@oracle.com
Charles Lever Charles Lever
Oracle Corporation Oracle Corporation
1015 Granger Avenue 1015 Granger Avenue
Ann Arbor, MI 48104 Ann Arbor, MI 48104
US US
Phone: +1 734 274 2396 Phone: +1 734 274 2396
Email: chuck.lever@oracle.com Email: chuck.lever@oracle.com
Bill Baker Bill Baker
 End of changes. 38 change blocks. 
87 lines changed or deleted 63 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/