Cc'ing NFSv3 mailing list.
On Jan 17, 2010, at 8:22 AM, Guillaume Rousse wrote:
Hello list.
A mandriva user report than unmount filesystem at shutdown is broken
since the move of {mount,unmount}.nfs commands from coreutils to
nfs-utils, some times ago:
https://qa.mandriva.com/show_bug.cgi?id=36490
It seems to be caused by the use of -l option in initscripts, which
apparently don't send an umount request to the server anymore. A
simple
test is enough to confirm it:
When using 'mount.nfs server:/dir dir && umount.nfs dir' on the
client,
the server logs:
Jan 17 14:01:12 mountd[18714]: authenticated mount request from
192.168.0.1:840 for /home (/home)
Jan 17 14:01:12 mountd[18714]: authenticated unmount request from
192.168.0.1:1012 for /home (/home)
When using 'mount.nfs server:/dir dir && umount.nfs dir -l' on the
client, the server logs:
Jan 17 14:09:17 mountd[18714]: authenticated mount request from
192.168.0.1:955 for /home (/home)
The filesystem is umounted client-side, but the server still thinks he
is connected:
[root@oberkampf Desktop]# showmount
Hosts on oberkampf:
192.168.0.1
client uses nfs-utils 1.2.0.
Reading the code in nfsumount.c, as suggested by comment #11
(https://qa.mandriva.com/show_bug.cgi?id=36490#c11) seems to imply
this
is on purpose:
if (mc) {
if (!lazy && strcmp(mc->m.mnt_type, "nfs4") != 0)
/* We ignore the error from nfs_umount23.
* If the actual umount succeeds (in del_mtab),
* we don't want to signal an error, as that
* could cause /sbin/mount to retry!
*/
nfs_umount23(mc->m.mnt_fsname, mc->m.mnt_opts);
ret = del_mtab(mc->m.mnt_fsname, mc->m.mnt_dir) ?: ret;
} else if (*spec != '/') {
if (!lazy)
ret = nfs_umount23(spec, "tcp,v3");
The description of this option seems to imply than he filesystem is
marked as unmounted right now in mtab, and than he is actually
umounted
properly as soon as possible. This doesn't says anything about the
server, tough, and I doesn't see anything in the code dealing with
this
'as soon as possible' event anyway...
The init scripts use "-l" because they don't want a hang at shutdown.
A hang might occur if the server is unreachable.
A UMNT is usually sent when the client knows it won't be using that
export any longer.
As far as I understand it, "-l" means the kernel will do the local
detach from the system's file name space whenever there are no more
users (ie entirely asynchronously). I don't think umount2(MNT_DETACH)
indicates whether the kernel was able to completely unmount that file
system by the time the call returns, so there's perhaps no way for
umount.nfs to know whether it should send the UMNT request. If the
server is slow or unresponsive, that file system won't be unmounted
until long after the umount.nfs command has exited.
This shouldn't be much of a big deal, since the server's rmtab is
"ornamental" according to the man page. No one should rely on it
being accurate.
A possible way to fix this is to have the kernel send the UMNT.
--
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
