NFS proxy-only mode

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
 
Line 2: Line 2:
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.
 +
 +
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?:
Possible implementation (needs more details).  v4 only for now?:
Line 11: Line 13:
- 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.
- 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.
+
- 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.
- 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