On Aug 25, 2009, at 3:18 PM, Steve Dickson wrote:
On 08/25/2009 02:59 PM, Chuck Lever wrote:
On Aug 25, 2009, at 1:55 PM, Steve Dickson wrote:
commit 1471d23d692efc7388794a8a3c3b9e548d1c5be8
Author: Steve Dickson <steved@xxxxxxxxxx>
Date: Tue Aug 25 12:15:18 2009 -0400
Make sure umount use correct fs type.
umounts use the fs type in /etc/mtab to determine
which file system is being unmounted. The mtab
entry is create during the mount. To ensure the
correct entry is create when the fs type changes
due to the mount options, the address of the fs_type
variable has to be passed so it can be updated.
In general, my policy is to record the user requested mount options
in
/etc/mtab, and let umount.nfs handle renegotiating as needed. For
version/transport this means that the server's configuration can
change
between the mount and the umount, and the umount will still work.
Perhaps this is not a consideration for NFSv4, but leaving the mount
options as specified by the user would save the need to update the fs
type, and would be a consistent policy for v2, v3, and v4. I think
it
would be cleaner to teach umount.nfs to do the right thing with "-t
nfs
-o v4" rather than rewriting the options in /etc/mtab.
Since nfs4 is truly a separate/different file system from nfs in the
kernel, I think we should continue making that distinction in system
files like mtab and /proc/mounts....
We are teaching mount.nfs not to care about nfs/nfs4 (at least
externally). Why should umount.nfs?
Also note there is no '-o ' flag to umount so 'umount -t nfs -o v4' is
not valid... but 'umount -t nfs' is and works on both nfs4 and nfs
file systems.
Sorry I wasn't clear. I meant that umount.nfs should be able to read
a line in /etc/mtab that has "nfs" and "v4" and do the right thing...
then you wouldn't have to change the fs_type in /etc/mtab at all.
--
Chuck Lever
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
