NFS proxy-only mode

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(One intermediate revision 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):
+
Possible implementation (needs more details).  v4 only for now?:
-
- Provide an interface to turn on this mode and identify the original server.  (I don't think the existing expkey/export cache upcalls will work.  Filehandles have to be treated as totally opaque in this case, but the kernel can't do an expkey upcall without doing some filehandle parsing first.  Maybe there'd be some way to hack it in there, but I think it would be ugly.)  The interface needs to be per-container.  Inclined just to create another file /proc/fs/nfsd/proxy-only to which you can write a server.  How would we identify a server?  Do we require an existing nfs mount, or take an address and do our own mount?  Note if we want to allow reexport of NFSv3, then we need userland help for the mount protocol part.  So, best may be to pass a path to an nfs mount.
+
- 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.

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.

Retrieved from "http://wiki.linux-nfs.org/wiki/index.php/NFS_proxy-only_mode"
Personal tools