Server export issues

From Linux NFS

---

Revision as of 15:37, 22 November 2010

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_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:

• 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?

• also allow root of export tree to start someplace other than

 /.  (Patches exist, need update.)