Server export issues

From Linux NFS

Revision as of 15:38, 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.)