linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: linux-nfs@vger.kernel.org
Cc: bfields@fieldses.org, luis.turcitu@appsbroker.com,
	chris.chilvers@appsbroker.com, david.young@appsbroker.com,
	daire@dneg.com, david.oberhollenzer@sigma-star.at,
	david@sigma-star.at, trond.myklebust@hammerspace.com,
	anna.schumaker@netapp.com, Richard Weinberger <richard@nod.at>
Subject: [RFC PATCH 0/3] Dealing with NFS re-export and cross mounts
Date: Mon, 10 Jan 2022 19:44:16 +0100	[thread overview]
Message-ID: <20220110184419.27665-1-richard@nod.at> (raw)

Currently when re-exporting a NFS share the NFS cross mount feature does
not work [0].
This RFC patch series outlines an approach to address the problem.

Crossing mounts does not work for two reasons:

1. As soon the NFS client (on the re-exporting server) sees a different
filesystem id, it installs an automount. That way the other filesystem
will be mounted automatically when someone enters the directory.
But the cross mount logic of KNFS does not know about automount.
The three patches in this series address the problem and teach both KNFSD
and the exportfs logic of NFS to deal with automount.

2. When KNFSD detects crossing of a mount point, it asks rpc.mountd to install
a new export for the target mount point. Beside of authentication rpc.mountd
also has to find a filesystem id for the new export. Is the to be exported
filesystem a NFS share, rpc.mountd cannot derive a filesystem id from it and
refuses to export. In the logs you’ll see error such as:
mountd: Cannot export /srv/nfs/vol0, possibly unsupported filesystem or fsid= required
To deal with that I changed rpc.mountd to use an arbitrary fsid.
Since this is a gross hack we need to agree on an approach to derive filesystem
ids for NFS mounts.

rpc.mountd could:
a) re-use the fsid from the original NFS server.
   Beside of requesting this information, the problem with that approach is
   that the original fsid might conflict with an existing export.
b) derive the fsid from stat->st_dev.
c) allocate a free fsid.
 
One use case to consider is load balancing. When multiple NFS servers re-export
a NFS mount, they need to use the same fsid for crossed mounts.
So I'm a little puzzled which approach is best. What do you think?

Known issues:
- Only tested with NFSv3 (both server and client) so far.

[0] https://marc.info/?l=linux-nfs&m=161653016627277&w=2

Richard Weinberger (3):
  NFSD: Teach nfsd_mountpoint() auto mounts
  fs: namei: Allow follow_down() to uncover auto mounts
  NFS: nfs_encode_fh: Remove S_AUTOMOUNT check

 fs/namei.c      | 2 +-
 fs/nfs/export.c | 5 -----
 fs/nfsd/vfs.c   | 2 +-
 3 files changed, 2 insertions(+), 7 deletions(-)

-- 
2.26.2


             reply	other threads:[~2022-01-10 18:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10 18:44 Richard Weinberger [this message]
2022-01-10 18:44 ` [RFC PATCH 1/3] NFSD: Teach nfsd_mountpoint() auto mounts Richard Weinberger
2022-01-10 18:44 ` [RFC PATCH 2/3] fs: namei: Allow follow_down() to uncover " Richard Weinberger
2022-01-10 18:44 ` [RFC PATCH 3/3] NFS: nfs_encode_fh: Remove S_AUTOMOUNT check Richard Weinberger
2022-01-11 19:43 ` [RFC PATCH 0/3] Dealing with NFS re-export and cross mounts J. Bruce Fields
2022-01-11 20:01   ` J. Bruce Fields
2022-01-11 20:02 ` 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=20220110184419.27665-1-richard@nod.at \
    --to=richard@nod.at \
    --cc=anna.schumaker@netapp.com \
    --cc=bfields@fieldses.org \
    --cc=chris.chilvers@appsbroker.com \
    --cc=daire@dneg.com \
    --cc=david.oberhollenzer@sigma-star.at \
    --cc=david.young@appsbroker.com \
    --cc=david@sigma-star.at \
    --cc=linux-nfs@vger.kernel.org \
    --cc=luis.turcitu@appsbroker.com \
    --cc=trond.myklebust@hammerspace.com \
    /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;
as well as URLs for NNTP newsgroup(s).