NFS proxy-only mode

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(Created page with "It could be useful to have a mode where an NFS server is dedicated to reexporting all the exports from *one* other NFS server. It would have no other exports whatsoever. This w...")
 
(3 intermediate revisions not shown)
Line 3: Line 3:
This would allow the re-export server to support crossmount-like behavior, skip adding its own filesystem identifier to each filehandle (fixing problems with filehandle length limits), and avoid the need for manual assignment of filesystem identifiers with the fsid= option.
This would allow the re-export server to support crossmount-like behavior, skip adding its own filesystem identifier to each filehandle (fixing problems with filehandle length limits), and avoid the need for manual assignment of filesystem identifiers with the fsid= option.
-
Possible implementation (needs more details):
+
Containers or virtualization could still allow a single physical machine to handle multiple exports even if desired.
-
- provide interface to turn on this mode and identify the original serverThis could be a new call to be made before starting nfsd, or it could use the export upcall to mountd somehow.
+
Possible implementation (needs more details)v4 only for now?:
-
- add a new export operation which accepts a filehandle and returns a superblock.
+
- Create a new /proc/fs/nfsd/proxy_only file.  Before starting the server, mount "/" on the original nfs server, then write the path to the mount to /proc/fs/nfsd/proxy_only.  This interface is per-container.  It also works for v3, which wouldn't currently possible with in-kernel mounting, though this feature is not as useful in that case as nested v3 mounts are rarer.
 +
 
 +
- the NFS mount can't allow redirection to other servers, unless those servers observe all the same filehandles.
 +
 
 +
- Given a filehandle, map to an export using a GETATTR to the server to get at least fsid, fileid, and file type.  If it's a directory, it should be possible to connect it up to the psuedoroot using LOOKUPP.  Find or create an export from the resulting struct path, cloing the parameters of the root export.
 +
 
 +
- If it's *not* a directory, and not already cached, then create a temporary vfsmount and export rooted at that one file.  If you've never seen this fsid before, you'll also have to create a superblock.  As far as I can tell, s_root on a given nfs superblock is not important, so it's OK for it to point at this file, even as it later accumulates the rest of the filesystem?  But I don't think that's true for export and vfsmount, hence the temporary objects.  I'm unclear on how to handle these "disconnected" vfsmounts.
 +
 
 +
- In theory, this could work with a filesystem other than NFS, if there was a filesystem or group of filesystems that coordinated their filehandles.

Latest revision as of 22:42, 19 January 2022

It could be useful to have a mode where an NFS server is dedicated to reexporting all the exports from *one* other NFS server. It would have no other exports whatsoever.

This would allow the re-export server to support crossmount-like behavior, skip adding its own filesystem identifier to each filehandle (fixing problems with filehandle length limits), and avoid the need for manual assignment of filesystem identifiers with the fsid= option.

Containers or virtualization could still allow a single physical machine to handle multiple exports even if desired.

Possible implementation (needs more details). v4 only for now?:

- Create a new /proc/fs/nfsd/proxy_only file. Before starting the server, mount "/" on the original nfs server, then write the path to the mount to /proc/fs/nfsd/proxy_only. This interface is per-container. It also works for v3, which wouldn't currently possible with in-kernel mounting, though this feature is not as useful in that case as nested v3 mounts are rarer.

- the NFS mount can't allow redirection to other servers, unless those servers observe all the same filehandles.

- Given a filehandle, map to an export using a GETATTR to the server to get at least fsid, fileid, and file type. If it's a directory, it should be possible to connect it up to the psuedoroot using LOOKUPP. Find or create an export from the resulting struct path, cloing the parameters of the root export.

- If it's *not* a directory, and not already cached, then create a temporary vfsmount and export rooted at that one file. If you've never seen this fsid before, you'll also have to create a superblock. As far as I can tell, s_root on a given nfs superblock is not important, so it's OK for it to point at this file, even as it later accumulates the rest of the filesystem? But I don't think that's true for export and vfsmount, hence the temporary objects. I'm unclear on how to handle these "disconnected" vfsmounts.

- In theory, this could work with a filesystem other than NFS, if there was a filesystem or group of filesystems that coordinated their filehandles.

Personal tools