NFS proxy-only mode
From Linux NFS
(Created page with "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 w...") |
|||
| Line 5: | Line 5: | ||
Possible implementation (needs more details): | Possible implementation (needs more details): | ||
| - | - | + | - 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. |
| + | |||
| + | - 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. | - add a new export operation which accepts a filehandle and returns a superblock. | ||
Revision as of 18:47, 19 April 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):
- 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.
- 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.
