Re: unmount -l does not send unmount request to the server

* Re: unmount -l does not send unmount request to the server
       [not found] <4B530EFF.9000205@inria.fr>
@ 2010-01-19 16:37 ` Chuck Lever
  2010-03-14 20:40   ` Guillaume Rousse
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Lever @ 2010-01-19 16:37 UTC (permalink / raw)
  To: Guillaume Rousse; +Cc: Linux NFS Mailing List, Linux NFSv4 mailing list

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

_______________________________________________
NFSv4 mailing list
NFSv4@linux-nfs.org
http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4

^ permalink raw reply	[flat|nested] 4+ messages in thread