public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
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
Date: Tue, 19 Jan 2021 13:02:04 -0500	[thread overview]
Message-ID: <20210119180204.GA24213@fieldses.org> (raw)
In-Reply-To: <CA+QRt4vb=DjgcOqGLtfdfKiDaqKED825xNpNyQaaK-df5tCSRQ@mail.gmail.com>

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?

  reply	other threads:[~2021-01-19 18:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18 17:57 Linux 5.11 Kernel: NFS re-export errors with older nfs-utils package versions Benjamin Maynard
2021-01-19 18:02 ` J. Bruce Fields [this message]
2021-01-21 11:21   ` Benjamin Maynard
2021-01-21 15:37     ` J. Bruce Fields
2021-01-21 17:46       ` Benjamin Maynard
2021-01-21 17:58         ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210119180204.GA24213@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=benmaynard@google.com \
    --cc=linux-nfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox