From patchwork Tue Nov 17 11:53:00 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jeff Layton X-Patchwork-Id: 7636351 Return-Path: X-Original-To: patchwork-linux-fsdevel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 83A25BF90C for ; Tue, 17 Nov 2015 11:54:31 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 6A42A204E2 for ; Tue, 17 Nov 2015 11:54:30 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3F27E204EA for ; Tue, 17 Nov 2015 11:54:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753631AbbKQLyN (ORCPT ); Tue, 17 Nov 2015 06:54:13 -0500 Received: from mail-qg0-f52.google.com ([209.85.192.52]:34886 "EHLO mail-qg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753634AbbKQLx6 (ORCPT ); Tue, 17 Nov 2015 06:53:58 -0500 Received: by qgec40 with SMTP id c40so3397821qge.2 for ; Tue, 17 Nov 2015 03:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=poochiereds_net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=VCtsmwyHy+mobcyup7IfaXYpvPrPiKiTHIVc6GVVd1s=; b=0Up9TZ/RaLZygX8QzTKXWCHXlKqjUbUAp0fPfnn4vcWvQqQyBLjAyM87KpkVoJHLuL /6Ks6zqRAlp27uiEboqOXDFOzF3fUmpkJ63SHf9O8IiCVyfKTqQhCe05P/ZOnYqTJ/1D ZU4PcF7ri4UOKFzTalcfIBtnt813r7uah65DLQWdAl7W1lVFUl9AZ6sqNCXremLdHucD K7ijMFXlRvECjLfZQuwyKSsrPWbUBBQU+KqY1k9o6FJWDhTiSEZZFRz1ZAmzBmpi+xRS MUL5/M8GAzfVtaRTR0nTDh/NPHpC07vxENoQHhLX84Dm9dWKewJMS8UxaYQgaRqPicSV k6qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=VCtsmwyHy+mobcyup7IfaXYpvPrPiKiTHIVc6GVVd1s=; b=Pet9H6qMiR3ishZVSu36dGCBip/7h67lA8a8bNIax8Yy+HMi1F6jQHP6eH23VXWCgv osxR1jg0oG83up98PGfdJhe2ZMh9yq1QUS+turfYM3KOfswsdoA4cP8hNa3AjCKyUhnb 6MEvuN688bLEaGFG8+z38lfQvJuNSCPxk9OvPgfBdnfjhLK9PzHmEpuKaWlAO7oEU2SH TNW2Oyucmyd5fsXeZJlR6EZp7vmItzHcuAfeShpzZZA5g3pe7SSS5ECqI8O4Osyg4kQa NlErKqjWcZMEo3Jpy5YGpgSw8KadU3AAbxo0suOhEVONUQZE0+WDkH1IT7an88ZlnB5Q zx7A== X-Gm-Message-State: ALoCoQm+NkuRefkuOKIYcyL5SGVsT5AtIwe6tuRMfzil0yIbuuD+j71igytm/KBKoTEFjkPjVHsf X-Received: by 10.140.102.35 with SMTP id v32mr41710061qge.72.1447761237205; Tue, 17 Nov 2015 03:53:57 -0800 (PST) Received: from tlielax.poochiereds.net ([2606:a000:1125:4075::d5a]) by smtp.googlemail.com with ESMTPSA id w10sm1583910qhc.16.2015.11.17.03.53.56 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 Nov 2015 03:53:56 -0800 (PST) From: Jeff Layton X-Google-Original-From: Jeff Layton To: bfields@fieldses.org, trond.myklebust@primarydata.com Cc: linux-nfs@vger.kernel.org, Eric Paris , Alexander Viro , linux-fsdevel@vger.kernel.org Subject: [PATCH v1 38/38] nfs: add a Kconfig option for NFS reexporting and documentation Date: Tue, 17 Nov 2015 06:53:00 -0500 Message-Id: <1447761180-4250-39-git-send-email-jeff.layton@primarydata.com> X-Mailer: git-send-email 2.4.3 In-Reply-To: <1447761180-4250-1-git-send-email-jeff.layton@primarydata.com> References: <1447761180-4250-1-git-send-email-jeff.layton@primarydata.com> Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@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: Jeff Layton --- Documentation/filesystems/nfs/reexport.txt | 95 ++++++++++++++++++++++++++++++ fs/nfs/Kconfig | 11 ++++ 2 files changed, 106 insertions(+) create mode 100644 Documentation/filesystems/nfs/reexport.txt diff --git a/Documentation/filesystems/nfs/reexport.txt b/Documentation/filesystems/nfs/reexport.txt new file mode 100644 index 000000000000..4ecfd3832338 --- /dev/null +++ b/Documentation/filesystems/nfs/reexport.txt @@ -0,0 +1,95 @@ +Re-exporting nfs via nfsd: +-------------------------- +It is possible to reeexport a nfs filesystem via nfsd, but there are +some limitations to this scheme. + +The primary use case for this is allowing clients that do not support +newer versions of NFS to access servers that do not export older +versions of NFS. In particular, it's a way to distribute pnfs support to +non-pnfs enabled clients (albeit at the cost of an extra hop). + +There are a number of caveats to doing this -- be sure to read the +entire document below and make sure that you know what you're doing! + +Quick Start: +------------ +1) ensure that the kernel is built with CONFIG_NFS_REEXPORT + +2) Mount the _entire_ directory tree that you wish to reexport on the +server. nfsd is unable to cross server filesystem boundaries +automatically, so the entire tree to be reexported must be mounted +prior to exporting. + +3) Add exports for the reexported filesystem to /etc/exports, assigning +fsid= values to each. NFS doesn't have a persistent UUID or device +number that is guaranteed to be unique across multiple servers, so +fsid= values must always be explicitly assigned. + +4) Avoid stateful operations from the clients. File locking is +particularly problematic, but reexporting NFSv4 via NFSv4 is likely to +have similar problems with open and delegation stateids as well. + +The gory details of reexportng: +------------------------------- +Below is a detailed list of the _known_ problems with reexporting NFS +via nfsd. Be aware of these facts when using this feature: + +Filehandle size: +---------------- +The maximum filehandle size is governed by the NFS version. Version 2 +used fixed 32 byte filehandles. Version 3 moved to variable length +filehandles that can be up to 64 bytes in size. NFSv4 increased that +maximum to 128 bytes. + +When reexporting an NFS filesystem, the underlying filehandle from the +server must be embedded inside the filehandles presented to clients. +Thus if the underlying server presents filehandles that are too big, the +reexporting server can fail to encode them. This can lead to +NFSERR_OPNOTSUPP errors being returned to clients. + +This is not a trivial thing to programatically determine ahead of time +(and it can vary even within the same server), so some foreknowledge of +how the underlying server constructs filehandles, and their maximum +size is a must. + +No subtree checking: +-------------------- +Subtree checking requires that information about the parent be encoded +in non-directory filehandles. Since filehandle space is already at a +premium, subtree checking is disallowed on reexported nfs filesystems. + +No crossing of mountpoints: +--------------------------- +Crossing from one exported filesystem to another typically involves the +nfs client doing a behind-the-scenes mount of the "child" filesystem. nfsd +lacks the machinery to do this. It could (in principle) be added, but +there's really no point as there is no way to ensure that the fsid +(filesystem identifier) value that got assigned was persistent. + +Lack of a persistent fsid= value: +--------------------------------- +NFS filesystems don't have a persistent value that we can stuff into +the fsid. We could repackage the one that the server provides, but that +could lead to collisions if the reexporting server has mounts to +different underlying servers. Thus, reexporting NFS requires assigning +a fsid= value in the export options. This value must be persistent +across reboots of the reexporting server as well or the clients will +see filehandles change (the dreaded "Stale NFS filehandle" error). + +Statefulness and locking: +------------------------- +Holding any sort of state across a reexported NFS mount is problematic. +It's always possible that the reexporting server could reboot, in which +case it will lose track of the state held on the underlying server. + +When it comes back up, the clients will then try to reclaim that state +from the reexporter, but the reexporter can't provide the necessary +guarantees to ensure that conflicting state wasn't set and released +during the time it was down. This may mean silent data corruption. +Any sort of stateful operations against the reexporting fileserver are +best avoided. + +Because of this, it's best to use a configuration that does not involve +the clients holding any state on the reexporter. For example, reexporting +a NFSv4 filesystem to legacy clients via NFSv3 (sans file locking) should +basically work. diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig index f31fd0dd92c6..92ad6bcc81cc 100644 --- a/fs/nfs/Kconfig +++ b/fs/nfs/Kconfig @@ -200,3 +200,14 @@ config NFS_DEBUG depends on NFS_FS && SUNRPC_DEBUG select CRC32 default y + +config NFS_REEXPORT + bool "Allow reexporting of NFS filesystems via knfsd" + depends on NFSD + default n + help + This option allows NFS filesystems to be re-exported via knfsd. + This is generally only useful in some very limited situations. + One such is to allow legacy client access to servers that do not + support older NFS versions. Use with caution and be sure to read + Documentation/filesystems/nfs/reexport.txt first!