NFS proxy-only mode
From Linux NFS
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 | + | - 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. | ||
- | - | + | - 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.