NFS proxy-only mode

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
 
(2 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 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.
+
Possible implementation (needs more details).  v4 only for now?:
-
- the nfs mount can't allow redirection to other servers, unless those servers observe all the same filehandles.
+
- 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.
-
- add a new export operation which accepts a filehandle and returns a superblock.
+
- 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.

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