Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 19 Jan 2021 13:02:04 -0500
To:     Benjamin Maynard <benmaynard@google.com>
Cc:     linux-nfs@vger.kernel.org
Subject: Re: Linux 5.11 Kernel: NFS re-export errors with older nfs-utils
 package versions
Message-ID: <20210119180204.GA24213@fieldses.org>
References: <CA+QRt4vb=DjgcOqGLtfdfKiDaqKED825xNpNyQaaK-df5tCSRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CA+QRt4vb=DjgcOqGLtfdfKiDaqKED825xNpNyQaaK-df5tCSRQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
From:   bfields@fieldses.org (J. Bruce Fields)
Precedence: bulk

On Mon, Jan 18, 2021 at 05:57:54PM +0000, Benjamin Maynard wrote:
> Hi,
> 
> I was recently experimenting with NFS re-exporting using the new patch
> set that is in the Linux 5.11 kernel
> (https://patchwork.kernel.org/project/linux-nfs/list/?series=393561).
> 
> After applying these patches, I consistently faced an error when
> trying to perform a previously working NFS re-export: "exportfs:
> /files does not support NFS export".
> 
> I (with help from some other interested parties) began troubleshooting
> and after stepping through each patch individually we identified that
> the error only occurred when the following patch was applied:
> https://patchwork.kernel.org/project/linux-nfs/patch/20201130220319.501064-3-trond.myklebust@hammerspace.com/.

That link isn't working for me for some reason.

Looks like we're talking about ba5e8187c555 "nfsd: allow filesystems to
opt out of subtree checking".

> This patch prevents re-exporting if subtree checking is enabled on the
> originating NFS server.

That's not correct.

I'm assuming there are two servers: a reexporting server, which mounts
the originating NFS server, which is mounting ext4 or xfs or some other
local filesystem.

It's hard for the reexporting server to even tell if the originating
server is using subtree checking, so I'm surprised that would make a
difference in behavior.

> The strange thing was that no_subtree_check
> export option was already set on the export from the originating NFS
> Filer, but the error message persisted.

So, this patch is only checks whether you've got no_subtree_check set on
the reexporting server.

> After lots of troubleshooting, eventually we tried updating NFS Utils
> from 1.3.4 to 2.5.2 and we were able to successfully perform
> re-export. It appears that the old version of the nfs-utils package
> was the cause of the issue.

I'm a little confused about what happened here.  Which server were you
applying the above patches on?  Which server did you upgrade NFS utils
on?

Could be that you're actually running into some filehandle size limit or
something.  (Subtree checking can make that problem worse.)  Hard to
tell.

--b.

> I appreciate that 1.3.4 is a very old version of nfs-utils, but it is
> the default version that ships with Ubuntu and Debian and the error
> message does not immediately point to the outdated version being the
> cause of the problem.
> 
> I was wondering if it was possible to detail the requirement for a
> more recent version of nfs-utils in the NFS Re-exporting section of
> the Wiki (http://wiki.linux-nfs.org/wiki/index.php/NFS_re-export) to
> help others who may encounter this problem in the future?