On Aug 25, 2009, at 4:49 PM, Trond Myklebust wrote:
On Tue, 2009-08-25 at 16:15 -0400, 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...
So, why couldn't we just do this in the kernel? It should be easily
doable to set nfs -overs=4 to mount an NFSv4 filesystem. We only
have to
do this for text mounts...
I think that would be a much better approach. If nfs4 goes away
someday, for example, it will be completely transparent to the mount
command if we've already pushed "-t nfs, vers=4" conversion into the
kernel.
We are pushing all of the details of NFS mounting into the kernel
anyway, over time. If we change the mount command now, and plan to
change the kernel in the future, that will make the mount command
balloon in complexity over time (if it's this kernel version, do this;
other kernel versions do that; yet others do something else). Yes, we
can make the mount command do that, but do we really want to make this
a policy for all new features that we can do it in mount first? One
of the reasons for text-based mounts was to do all this in the kernel
so we don't have feature dependencies on user space.
We have already fixed version/transport negotiation in the mount
command with the promise that the kernel will handle it later; I think
that will be an issue down the road. In the version/transport case,
though, that feature had already been widely deployed, so an immediate
fix was nearly mandatory. For vers=4, we still have an opportunity to
think ahead.
Another advantage is that this would provide cleaner NFSROOT v4 support.
The problem with having the kernel handle the version upgrade, though,
is that the NFS super code paths would need to convert the mount to an
nfs4 file system type when vers=4 is detected. I looked at that a
little last week, and it looked potentially pretty wonky. Maybe you
have an idea how to make this easy?
Note also that if the kernel does the vers=4 processing instead of the
mount command, we would have to change the umount command as I
described before anyway.
--
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
