* [PATCH] nfs(5): Document the "migration" mount option
@ 2013-09-10 19:26 Chuck Lever
0 siblings, 0 replies; 6+ messages in thread
From: Chuck Lever @ 2013-09-10 19:26 UTC (permalink / raw)
To: linux-nfs
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...?
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH] nfs(5): Document the "migration" mount option
@ 2013-09-10 19:28 Chuck Lever
2013-09-18 15:57 ` Steve Dickson
2013-11-20 21:21 ` Steve Dickson
0 siblings, 2 replies; 6+ messages in thread
From: Chuck Lever @ 2013-09-10 19:28 UTC (permalink / raw)
To: linux-nfs
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...?
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] nfs(5): Document the "migration" mount option
2013-09-10 19:28 Chuck Lever
@ 2013-09-18 15:57 ` Steve Dickson
2013-11-20 21:21 ` Steve Dickson
1 sibling, 0 replies; 6+ messages in thread
From: Steve Dickson @ 2013-09-18 15:57 UTC (permalink / raw)
To: Chuck Lever; +Cc: linux-nfs
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] nfs(5): Document the "migration" mount option
@ 2013-11-14 16:35 Chuck Lever
2013-11-20 21:23 ` Steve Dickson
0 siblings, 1 reply; 6+ messages in thread
From: Chuck Lever @ 2013-11-14 16:35 UTC (permalink / raw)
To: steved; +Cc: linux-nfs
Support for NFSv4 migration was merged in 3.13.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
utils/mount/nfs.man | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/utils/mount/nfs.man b/utils/mount/nfs.man
index 2a42b93..8535aec 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 newer than zero,
+which always use TSM-compatible client identification strings.
.SH nfs4 FILE SYSTEM TYPE
The
.BR nfs4
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] nfs(5): Document the "migration" mount option
2013-09-10 19:28 Chuck Lever
2013-09-18 15:57 ` Steve Dickson
@ 2013-11-20 21:21 ` Steve Dickson
1 sibling, 0 replies; 6+ messages in thread
From: Steve Dickson @ 2013-11-20 21:21 UTC (permalink / raw)
To: Chuck Lever, linux-nfs
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...?
Committed (tag: nfs-utils-1-2-10-rc1)
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] nfs(5): Document the "migration" mount option
2013-11-14 16:35 [PATCH] nfs(5): Document the "migration" mount option Chuck Lever
@ 2013-11-20 21:23 ` Steve Dickson
0 siblings, 0 replies; 6+ messages in thread
From: Steve Dickson @ 2013-11-20 21:23 UTC (permalink / raw)
To: Chuck Lever; +Cc: linux-nfs
On 14/11/13 11:35, Chuck Lever wrote:
> Support for NFSv4 migration was merged in 3.13.
>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Committed (tag: nfs-utils-1-2-10-rc1)
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..8535aec 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 newer than zero,
> +which always use TSM-compatible client identification strings.
> .SH nfs4 FILE SYSTEM TYPE
> The
> .BR nfs4
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-11-20 21:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-11-14 16:35 [PATCH] nfs(5): Document the "migration" mount option Chuck Lever
2013-11-20 21:23 ` Steve Dickson
-- strict thread matches above, loose matches on Subject: below --
2013-09-10 19:28 Chuck Lever
2013-09-18 15:57 ` Steve Dickson
2013-11-20 21:21 ` Steve Dickson
2013-09-10 19:26 Chuck Lever
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).