Server export issues

From Linux NFS

(Difference between revisions)
Jump to: navigation, search
(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?
-
  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.
-
  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_support9) 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:
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.
-
  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
-
  mount /foo
+
** 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?
-
  loopback?
+
* 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
+
-
  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:
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.)
-
  unless it's also a mountpoint.  We should fix this.  (We
+
* support symlinks (kernel is ready for this, mountd probably needs patching).  
-
  should also discourage this, as users rarely seem to
+
* 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.
-
  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.
* 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.)
-
  look up "/", falling back on fsid=0 (for backwards
+
* 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.
-
  compatibility) only if the lookup for "/" fails.  (I'd like to
+
* 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?
-
  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?
+
-
* also allow root of export tree to start someplace other than
+
-
  /.  (Patches exist, need update.)
+

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?
Personal tools