On Jan 9, 2014, at 14:12, Jeff Layton <jlayton@xxxxxxxxxx> wrote: > On Thu, 9 Jan 2014 14:06:54 -0500 > Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > >> >> On Jan 9, 2014, at 13:59, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >> >>> The nfs code will currently construct a devname to show in places like >>> /proc/mounts by turning a dentry into a path. Unfortunately, that's >>> somewhat problematic if the user ended up mounting through a symlink on >>> the server. The devname that then shows up in /proc/mounts now doesn't >>> match the one that was originally passed into the mount request. >> >> This is 100% according to design. Why is it suddenly a problem? >> >> By displaying the original pathname, you also end up bypassing referral resolution, etc. This is exactly why the .show_devname operation was introduced in the first place. >> > > AFAIU, the main issue is that when /etc/mtab is a symlink > to /proc/mounts, you can't do this in the example in the patch > description: > > # mount server:/export/bar /mnt/bar > # umount server:/export/bar > > ...since umount will try to ID the mountpoint by looking up the devname > in /etc/mtab. The NFS pathname is NOT a devname. It shouldn’t be abused as a substitute for a mount point. Particularly not so when you consider that the same NFS path can be mounted in several different places with different mount options. The same path can even refer to completely different locations (i.e. different file handles) if, say, the original directory has been renamed on the server. > What exactly would this break with referrals? > It would “break” in the sense that the admin would have no clue that his client is actually talking to a different server than the one specified in the mount. -- Trond Myklebust Linux NFS client maintainer -- 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
