On Aug 25, 2009, at 4:15 PM, Steve Dickson wrote:
On 08/25/2009 03:32 PM, Chuck Lever wrote:
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?
That's not quite accurate... IMHO.. I see it as we are teach
mount.nfs to
accept new command line arguments that will cause a nfs4 file system
to be mounted... and that is done by caring which fs type mount is
dealing with...
Right. I think umount.nfs should get the same treatment. But it gets
it's "command line arguments" from /etc/mtab.
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.
Ok.. I gotta you now... and I did take a few minutes to look into what
something like this would take... I quickly came to the realization
that adding all complexity to make a system file, that nobody see or
care about, more aesthetic really not worth it and not necessary,
IMHO....
It's more of a maintainability issue. Make umount.nfs behave the same
way for v2, v3, and v4, instead of doing one thing for v2/v3 and
another for v4.
Point being, umount is so simple when it comes to umounting a nfs4
file
system... It basically does nothing! Which is a beautiful thing! So
to added
all the code (on both the mount and umount side) to translate
'-t nfs -o v4' into nfs4 (which would have to happen since
del_mtab() takes a fs type) is just not worth it... Especially when
the other option is adding no code to the umount side...
I doubt it would be a lot of complexity, actually. We already have
parser calls in umount.nfs to handle v2/v3 version/transport
negotiation, so I don't think it would be much of a stretch at all to
look for "v4" before deciding whether to do a v2/v3 umount or a v4
umount.
--
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
