NFS proxy-only mode

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
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):
+
Possible implementation (needs more details).  v4 only for now?:
-
- Create a new /proc/fs/nfsd/proxy_only file.  Before starting the server, mount 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 terribly useful in that case as nested v3 mounts are rarer.
+
- 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.
- the NFS mount can't allow redirection to other servers, unless those servers observe all the same filehandles.
-
- add a new export operation which accepts a filehandle and returns a superblock.
+
- 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.
- In theory, this could work with a filesystem other than NFS, if there was a filesystem or group of filesystems that coordinated their filehandles.
- In theory, this could work with a filesystem other than NFS, if there was a filesystem or group of filesystems that coordinated their filehandles.

Revision as of 19:12, 13 May 2021

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.

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.

- 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