unmount -l does not send unmount request to the server

[Guillaume Rousse]

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 at 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...

[Chuck Lever]

Cc'ing NFSv3 mailing list.

Post by Guillaume Rousse
Hello list.
A mandriva user report than unmount filesystem at shutdown is broken
since the move of {mount,unmount}.nfs commands from coreutils to
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
When using 'mount.nfs server:/dir dir && umount.nfs dir' on the client,
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
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
[root at oberkampf Desktop]# showmount
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
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]

Post by Chuck Lever
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.

It makes sense, but it doesn't seem to trigger much interest :)
Should I open a bug somewhere, to ensure the issue won't be forgotten ?

You might consider filing a bug in the NFSv4 bugzilla on linux-nfs.org.

[Trond Myklebust]

Post by Chuck Lever

Post by Chuck Lever
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.

It makes sense, but it doesn't seem to trigger much interest :)
Should I open a bug somewhere, to ensure the issue won't be forgotten ?

You might consider filing a bug in the NFSv4 bugzilla on linux-nfs.org.

1) What does this have to do with NFSv4?

2) I don't have to do lazy umounts in order to confuse umount.nfs.
Consider

mount -t nfs foo:/bar /mnt1
mount --bind /mnt1 /mnt2
umount /mnt1
umount /mnt2

3) Even the kernel doesn't know what to do in all cases, because it
doesn't know whether or not a mount rpc call was sent or not for each
mountpoint that you do a 'umount /mnt' on. Consider the case where you
do a clone(CLONE_NEWNS), and then the user does 'umount /mnt' in _one_
of those namespaces.

IOW: Please just accept that this is a feature, not a bug. Nobody
promised you that the mountd statistics would be 100% accurate, and
we're certainly not going to waste time trying to make it so.

Trond

[Guillaume Rousse]

Post by Trond Myklebust
IOW: Please just accept that this is a feature, not a bug. Nobody
promised you that the mountd statistics would be 100% accurate, and
we're certainly not going to waste time trying to make it so.

OK, this is not really critical, but if the behaviour change, we have to
handle it in our initscripts.

I guess the main interest of this option was to be able to unmount the
file system asynchronously from the server, in order to not be blocked
by a non-responding server. If it's difficult to keep a process running
so as to delay the sending of the umount request later, would it be
possible instead to send it immediatly, but ignoring the server answer
(or lack of answer) ? This way, we could still get accurate server-side
clients tracking at no cost, if the server is responding, without
blocking the client if it is not.

If not possible, the option description ought to be updated in the man page:
Lazy unmount. Detach the file system from the file system hierarchy now,
and cleanup all references to the file system as soon as it is not busy
anymore. Warning, using this option will prevent an umount request to be
sent to the server, making mountd erroneous on server side.

[J. Bruce Fields]

Post by Guillaume Rousse

Post by Trond Myklebust
IOW: Please just accept that this is a feature, not a bug. Nobody
promised you that the mountd statistics would be 100% accurate, and
we're certainly not going to waste time trying to make it so.

OK, this is not really critical, but if the behaviour change, we have to
handle it in our initscripts.
I guess the main interest of this option was to be able to unmount the
file system asynchronously from the server, in order to not be blocked
by a non-responding server. If it's difficult to keep a process running
so as to delay the sending of the umount request later, would it be
possible instead to send it immediatly, but ignoring the server answer
(or lack of answer) ? This way, we could still get accurate server-side
clients tracking at no cost, if the server is responding, without
blocking the client if it is not.
Lazy unmount. Detach the file system from the file system hierarchy now,
and cleanup all references to the file system as soon as it is not busy
anymore. Warning, using this option will prevent an umount request to be
sent to the server, making mountd erroneous on server side.

OK, but "making mountd erroneous" doesn't mean much to me.

--b.

[Chuck Lever]

Post by Guillaume Rousse

Post by Trond Myklebust
IOW: Please just accept that this is a feature, not a bug. Nobody
promised you that the mountd statistics would be 100% accurate, and
we're certainly not going to waste time trying to make it so.

OK, this is not really critical, but if the behaviour change, we have to
handle it in our initscripts.
I guess the main interest of this option was to be able to unmount the
file system asynchronously from the server, in order to not be blocked
by a non-responding server. If it's difficult to keep a process running
so as to delay the sending of the umount request later, would it be
possible instead to send it immediatly, but ignoring the server answer
(or lack of answer) ? This way, we could still get accurate server-side
clients tracking at no cost, if the server is responding, without
blocking the client if it is not.

The mount program provided in nfs-utils 1.2.1 does this already. The
RPC timeout when sending a UMNT request is quite short, on the order of
3 seconds. UMNT is treated as advisory.

[Guillaume Rousse]

Post by Chuck Lever

Post by Guillaume Rousse
I guess the main interest of this option was to be able to unmount the
file system asynchronously from the server, in order to not be blocked
by a non-responding server. If it's difficult to keep a process running
so as to delay the sending of the umount request later, would it be
possible instead to send it immediatly, but ignoring the server answer
(or lack of answer) ? This way, we could still get accurate server-side
clients tracking at no cost, if the server is responding, without
blocking the client if it is not.

The mount program provided in nfs-utils 1.2.1 does this already. The
RPC timeout when sending a UMNT request is quite short, on the order of
3 seconds. UMNT is treated as advisory.

with or without -l option ?

[Chuck Lever]

Post by Guillaume Rousse

Post by Chuck Lever

Post by Guillaume Rousse
I guess the main interest of this option was to be able to unmount the
file system asynchronously from the server, in order to not be blocked
by a non-responding server. If it's difficult to keep a process running
so as to delay the sending of the umount request later, would it be
possible instead to send it immediatly, but ignoring the server answer
(or lack of answer) ? This way, we could still get accurate server-side
clients tracking at no cost, if the server is responding, without
blocking the client if it is not.

The mount program provided in nfs-utils 1.2.1 does this already. The
RPC timeout when sending a UMNT request is quite short, on the order of
3 seconds. UMNT is treated as advisory.

with or without -l option ?

umount.nfs uses a short timeout now whenever it sends UMNT.

Using "-l" or unmounting an NFSv4 mount causes umount.nfs to skip sending UMNT.