Server export issues
From Linux NFS
(Difference between revisions)
(Created page with 'Bugs that people might hit any day now: * Are there people that use root filesystems that do *not* support NFS exports? * YUP: make sure nfs-utils handles this; if nothing el…') |
|||
| (5 intermediate revisions not shown) | |||
| Line 1: | Line 1: | ||
Bugs that people might hit any day now: | Bugs that people might hit any day now: | ||
| - | * Are there people that use root filesystems that do *not* | + | * Are there people that use root filesystems that do *not* support NFS exports? |
| - | + | * YUP: make sure nfs-utils handles this; if nothing else, it should error out and give up on automatic nfsv4 support. But document this and make sure it's OK with people. Failures of this sort don't look like they're handled well right now; see e.g. v4root_support() in nfs-utils: looks inadequate. Make sure we turn off v4 root entirely if we can't cook up a pseudoroot somewhere (to avoid returning dumb errors on GETROOTFH). | |
| - | * YUP: make sure nfs-utils handles this; if nothing | + | * In my testing I didn't find crossmnt to be reliable; it didn't always seem to export subfilesystem as I expected, and in other cases seemed to override options on explicitly exported sub-mounts. Test, write up behavior we decide is correct, and implement. |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | * In my testing I didn't find crossmnt to be reliable; it didn't | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
Less urgent, but eventual large benefits: | Less urgent, but eventual large benefits: | ||
* write basic exports regression tests: | * write basic exports regression tests: | ||
| - | * run various exportfs commands on server, test the | + | ** run various exportfs commands on server, test the results on the client. |
| - | + | ** mountpoint at /export, mount /, mount /export; | |
| - | * mountpoint at /export, mount /, mount /export; | + | ** mountpoint at /export/foo, mount /, mount /export, mount /foo |
| - | * mountpoint at /export/foo, mount /, mount /export, | + | ** etc.; make list of cases |
| - | + | ** assume kernel client available, and do testing over loopback? | |
| - | * etc.; make list of cases | + | ** Assume presence of tmpfs usable for export setup? |
| - | * assume kernel client available, and do testing over | + | ** Look into using Jeff's new framework? |
| - | + | * Write design for Documentation/. Some points: | |
| - | * Assume presence of tmpfs usable for export setup? | + | ** Note it's OK that we restrict pseudoroot to clients that can access some subexport, since clients that match *no* auth_domain are rejected at the rpc level. |
| - | * Look into using Jeff's new framework? | + | ** Document is about mountd<->kernel interface (as opposed to, say, knfsd<->filesystem interface) |
| - | * Write design for Documentation/. Some points: | + | |
| - | * Note it's OK that we restrict pseudoroot to clients | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | * Document is about mountd<->kernel interface (as | + | |
| - | + | ||
Lower-priority bugs/wishlist: | Lower-priority bugs/wishlist: | ||
| - | * Currently NFSv4 won't notice when we cross an export boundary | + | * Currently NFSv4 won't notice when we cross an export boundary unless it's also a mountpoint. We should fix this. (We should also discourage this, as users rarely seem to understand the associated filehandle-guessing attacks.) |
| - | + | * support symlinks (kernel is ready for this, mountd probably needs patching). | |
| - | + | * v4root_set, auth_reload, etc., all need to be able to return errors on memory allocation failure. Final result should probably be to drop (not reply to) requests, whether from mount clients or from kernel; eventually there will be a retry. That's unfortunate, but it's better than returning spurious ENOENT or -ESTALE to clients due to missing export, etc., or crashing mountd completely on any allocation failure. | |
| - | + | ||
| - | * support symlinks (kernel is ready for this, mountd probably | + | |
| - | + | ||
| - | * v4root_set, auth_reload, etc., all need to be able to return | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
* should be hiding referral exports from MOUNT clients. | * should be hiding referral exports from MOUNT clients. | ||
| - | * Teach the kernel to do psuedoroot lookups by first trying to | + | * Teach the kernel to do psuedoroot lookups by first trying to look up "/", falling back on fsid=0 (for backwards compatibility) only if the lookup for "/" fails. (I'd like to eliminate the dependence on the fsid=0 convention.) |
| - | + | * Remove the dependence of the v4root stuff on filehandles that have the dentry encoded into the fsid part. That needs some more work, but I think it's doable. That allows us to keep filehandles the same between v4- and non-v4-root exports, at which point I think we can make "v4root" another option that varies by pseudoflavor, which should solve some of these nested export problems. | |
| - | + | * export cache upcall uses stringified path names, but is internally keyed on (vfsmnt, dentry). So if you have a mountpoint at /export/foo/bar, then mount something on top of /foo, but export only /export, then clients will hang when they get to /export/foo/bar. There may be other scenarios also involving exports that change over time? | |
| - | + | ||
| - | * Remove the dependence of the v4root stuff on filehandles that | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | * export cache upcall uses stringified path names, but is | + | |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
Latest revision as of 19:47, 15 December 2020
Bugs that people might hit any day now:
- Are there people that use root filesystems that do *not* support NFS exports?
- YUP: make sure nfs-utils handles this; if nothing else, it should error out and give up on automatic nfsv4 support. But document this and make sure it's OK with people. Failures of this sort don't look like they're handled well right now; see e.g. v4root_support() in nfs-utils: looks inadequate. Make sure we turn off v4 root entirely if we can't cook up a pseudoroot somewhere (to avoid returning dumb errors on GETROOTFH).
- In my testing I didn't find crossmnt to be reliable; it didn't always seem to export subfilesystem as I expected, and in other cases seemed to override options on explicitly exported sub-mounts. Test, write up behavior we decide is correct, and implement.
Less urgent, but eventual large benefits:
- write basic exports regression tests:
- run various exportfs commands on server, test the results on the client.
- mountpoint at /export, mount /, mount /export;
- mountpoint at /export/foo, mount /, mount /export, mount /foo
- etc.; make list of cases
- assume kernel client available, and do testing over loopback?
- Assume presence of tmpfs usable for export setup?
- Look into using Jeff's new framework?
- Write design for Documentation/. Some points:
- Note it's OK that we restrict pseudoroot to clients that can access some subexport, since clients that match *no* auth_domain are rejected at the rpc level.
- Document is about mountd<->kernel interface (as opposed to, say, knfsd<->filesystem interface)
Lower-priority bugs/wishlist:
- Currently NFSv4 won't notice when we cross an export boundary unless it's also a mountpoint. We should fix this. (We should also discourage this, as users rarely seem to understand the associated filehandle-guessing attacks.)
- support symlinks (kernel is ready for this, mountd probably needs patching).
- v4root_set, auth_reload, etc., all need to be able to return errors on memory allocation failure. Final result should probably be to drop (not reply to) requests, whether from mount clients or from kernel; eventually there will be a retry. That's unfortunate, but it's better than returning spurious ENOENT or -ESTALE to clients due to missing export, etc., or crashing mountd completely on any allocation failure.
- should be hiding referral exports from MOUNT clients.
- Teach the kernel to do psuedoroot lookups by first trying to look up "/", falling back on fsid=0 (for backwards compatibility) only if the lookup for "/" fails. (I'd like to eliminate the dependence on the fsid=0 convention.)
- Remove the dependence of the v4root stuff on filehandles that have the dentry encoded into the fsid part. That needs some more work, but I think it's doable. That allows us to keep filehandles the same between v4- and non-v4-root exports, at which point I think we can make "v4root" another option that varies by pseudoflavor, which should solve some of these nested export problems.
- export cache upcall uses stringified path names, but is internally keyed on (vfsmnt, dentry). So if you have a mountpoint at /export/foo/bar, then mount something on top of /foo, but export only /export, then clients will hang when they get to /export/foo/bar. There may be other scenarios also involving exports that change over time?
