From patchwork Tue Sep 10 19:26:27 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chuck Lever X-Patchwork-Id: 2867481 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 E72AC9F495 for ; Tue, 10 Sep 2013 19:26:37 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id CA05F201C7 for ; Tue, 10 Sep 2013 19:26:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 83D3D202B3 for ; Tue, 10 Sep 2013 19:26:35 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751828Ab3IJT0d (ORCPT ); Tue, 10 Sep 2013 15:26:33 -0400 Received: from mail-vb0-f51.google.com ([209.85.212.51]:58575 "EHLO mail-vb0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751346Ab3IJT0b (ORCPT ); Tue, 10 Sep 2013 15:26:31 -0400 Received: by mail-vb0-f51.google.com with SMTP id x16so5455183vbf.10 for ; Tue, 10 Sep 2013 12:26: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=uNrW+l7VIhQULyChjuBoeFuDnwGo9XcjcImdW2bfNRa4y14sPnCowrPewkFMpDypBZ 5wU2H89IwgEt3qhtzFr+MFHQJ0F1YqVCWLu2Cui3FiZdY4Wpi/TT3wQwSq/dyTquWBq0 AojZNERo5rAeqDG0DBMif4v23yQdEN3apPB+CJA2Gcyac2iMo3zKI2urC99f2EJ0a6Z+ 3DdVzFDsa9ZcDzvz16rKU7vk2rfhQNfN8pm56RNjG2P+RtyOycxqVlKXcBpq0q5OcXyN eoGMcJ1SXUd4fYErezQkm4GaosEoLP6BcU/4wFTu3K0e5MmSz9FK+PnAY35HcagwX/ZT xQHw== X-Received: by 10.52.162.66 with SMTP id xy2mr19399540vdb.3.1378841190185; Tue, 10 Sep 2013 12:26:30 -0700 (PDT) Received: from seurat.1015granger.net ([2604:8800:100:81fc:20c:29ff:fe44:ec31]) by mx.google.com with ESMTPSA id m6sm6422468vdi.8.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 10 Sep 2013 12:26:29 -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:26:27 -0400 Message-ID: <20130910190721.2269.70727.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