From patchwork Tue Sep 10 19:28:28 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 2867551 Return-Path: X-Original-To: patchwork-linux-nfs@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 708BB9F2D6 for ; Tue, 10 Sep 2013 19:28:35 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 5DDB1201C7 for ; Tue, 10 Sep 2013 19:28:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2B2232018E for ; Tue, 10 Sep 2013 19:28:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751611Ab3IJT2c (ORCPT ); Tue, 10 Sep 2013 15:28:32 -0400 Received: from mail-ve0-f177.google.com ([209.85.128.177]:34281 "EHLO mail-ve0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751394Ab3IJT2b (ORCPT ); Tue, 10 Sep 2013 15:28:31 -0400 Received: by mail-ve0-f177.google.com with SMTP id db12so4818778veb.22 for ; Tue, 10 Sep 2013 12:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:from:date:message-id:user-agent:mime-version :content-type:content-transfer-encoding; bh=3NA7wz+q1NAK/pHxaI8Jlq7HoSpTRrJ8E9hQGgeQTSk=; b=hp7N9YdGiNCYoouYxA+Y4SQW4gRaFjUilixixVCKu0/kYFwK/Gw3vwGvz+21OGaZzu 2DBe2SAkNE1g9v8MECChQV2uCuuOIOJA/DrrLH8XcVYtmHOoos+95eMcknxqsEKD5KsN ydfv2L/Qmf4M7JaA/vb4iOHO3Cq0PTx5JJ3Lm65vkanVzO55OP2zTpfQKx831NuCztWR 1tsW021Dc+JArWS4AK0pWeN1fMtsfPX8CXBAkF5xgNiC9suNmoexne1gQOHtfRlFvgTA +NM7e0SPNDVE5wqSpU+nIXoofVXNwUTHQ0BNx6b6LH1JUFab2ONxx0NFFajlocs4y7Wz kBAw== X-Received: by 10.52.37.69 with SMTP id w5mr1821685vdj.32.1378841310892; Tue, 10 Sep 2013 12:28:30 -0700 (PDT) Received: from seurat.1015granger.net ([2604:8800:100:81fc:20c:29ff:fe44:ec31]) by mx.google.com with ESMTPSA id k17sm4511024vdh.7.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 10 Sep 2013 12:28:30 -0700 (PDT) Subject: [PATCH] nfs(5): Document the "migration" mount option To: linux-nfs@vger.kernel.org From: Chuck Lever Date: Tue, 10 Sep 2013 15:28:28 -0400 Message-ID: <20130910192730.2394.8803.stgit@seurat.1015granger.net> User-Agent: StGit/0.16 MIME-Version: 1.0 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Signed-off-by: Chuck Lever --- 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(+) -- 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 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