Re: [PATCH] nfs(5): Document the "migration" mount option

[Steve Dickson <SteveD@redhat.com>]

On 10/09/13 15:28, Chuck Lever wrote:
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> 
> This has been floating around for a while in my nfs-utils repo.
> Now that migration support is getting merged upstream, I propose
> this minor change to nfs(5).
> 
> Note that my pending migration patches currently allow migration
> even if the "migration" option is not specified.  In this case,
> standard state recovery will occur on the destination server (aka a
> non-TSM migration) since the destination server can't match up a
> client using the traditional clientid string with incoming migrated
> state.
> 
> If we think this is dangerous to allow, then the client can be
> changed to require the "migration" option to enable migration
> support on NFSv4.0 mount points.
> 
> Non-TSM migration can still occur if the servers for some reason
> fail to transfer open and lock state during a migration.
> 
> Comments...?
This looks find to me... When the migration code "hits the streets"
I'll commit this... Until then I'll keep on my TODO que... 

steved.
 
> 
>  utils/mount/nfs.man |   20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
> index 2a42b93..e93bd16 100644
> --- a/utils/mount/nfs.man
> +++ b/utils/mount/nfs.man
> @@ -855,6 +855,26 @@ In the presence of multiple client network interfaces,
>  special routing policies,
>  or atypical network topologies,
>  the exact address to use for callbacks may be nontrivial to determine.
> +.TP 1.5i
> +.BR migration " / " nomigration
> +Selects whether the client uses an identification string that is compatible
> +with NFSv4 Transparent State Migration (TSM).
> +If the mounted server supports NFSv4 migration with TSM, specify the
> +.B migration
> +option.
> +.IP
> +Some server features misbehave in the face of a migration-compatible
> +identification string.
> +The
> +.B nomigration
> +option retains the use of a traditional client indentification string
> +which is compatible with legacy NFS servers.
> +This is also the behavior if neither option is specified.
> +A client's open and lock state cannot be migrated transparently
> +when it identifies itself via a traditional identification string.
> +.IP
> +This mount option has no effect with NFSv4 minor versions greater than zero,
> +as these versions always use TSM-compatible client identification strings.
>  .SH nfs4 FILE SYSTEM TYPE
>  The
>  .BR nfs4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>