I've been looking at a bug where "mount.nfs -o remount" wipes all the mount options for that mount out of /etc/mtab, thereby making umounting break. This is a tough nut to crack in user space... Not even utils-linux-ng seems to get mtab option rewriting correct in this case. Jeff suggested a few weeks ago that we should just chuck user space umount and go with a kernel umount implementation. I'm beginning to think that is a good strategy, even though a UMNT request is advisory. + Only the kernel knows when the last instance of a shared mount point is gone -- only then should a UMNT be sent to the server + The kernel might do a delayed lazy UMNT. It would avoid sending a UMNT until the client is actually done using the export. Today we just don't send UMNT at all in this case + The kernel preserves the original mount options in an internal data structure rather than in /etc/mtab, even after a remount. This eliminates the NFS requirement for /etc/mtab -- one step closer to getting rid of it + The kernel already handles umounts for under-the-cover NFSv4 mounts, right? + The kernel is the authority on what is an NFSv4 mount point, so it knows exactly what kind of umount to do every time (send a UMNT or not) + There is already a UMNT client in the kernel, used when the kernel's MNT request fails such that a UMNT is needed Thoughts, comments? -- chuck[dot]lever[at]oracle[dot]com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
