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

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

[Chuck Lever]

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

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

[Guillaume Rousse]

Le 19/01/2010 17:37, Chuck Lever a =E9crit :
> 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 ?
-- =

BOFH excuse #196:

Me no internet, only janitor, me just wax floors.

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

[Chuck Lever]

On 03/14/2010 04:40 PM, Guillaume Rousse wrote:
> Le 19/01/2010 17:37, Chuck Lever a =E9crit :
>> 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_DETAC=
H)
>> indicates whether the kernel was able to completely unmount that fil=
e
>> 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 be=
ing
>> 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.

--=20
chuck[dot]lever[at]oracle[dot]com

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

[Trond Myklebust]

T24gRnJpLCAyMDEwLTAzLTE5IGF0IDE2OjIyIC0wNDAwLCBDaHVjayBMZXZlciB3cm90ZTogCj4g
T24gMDMvMTQvMjAxMCAwNDo0MCBQTSwgR3VpbGxhdW1lIFJvdXNzZSB3cm90ZToKPiA+IExlIDE5
LzAxLzIwMTAgMTc6MzcsIENodWNrIExldmVyIGEgw6ljcml0IDoKPiA+PiBBcyBmYXIgYXMgSSB1
bmRlcnN0YW5kIGl0LCAiLWwiIG1lYW5zIHRoZSBrZXJuZWwgd2lsbCBkbyB0aGUgbG9jYWwKPiA+
PiBkZXRhY2ggZnJvbSB0aGUgc3lzdGVtJ3MgZmlsZSBuYW1lIHNwYWNlIHdoZW5ldmVyIHRoZXJl
IGFyZSBubyBtb3JlCj4gPj4gdXNlcnMgKGllIGVudGlyZWx5IGFzeW5jaHJvbm91c2x5KS4gIEkg
ZG9uJ3QgdGhpbmsgdW1vdW50MihNTlRfREVUQUNIKQo+ID4+IGluZGljYXRlcyB3aGV0aGVyIHRo
ZSBrZXJuZWwgd2FzIGFibGUgdG8gY29tcGxldGVseSB1bm1vdW50IHRoYXQgZmlsZQo+ID4+IHN5
c3RlbSBieSB0aGUgdGltZSB0aGUgY2FsbCByZXR1cm5zLCBzbyB0aGVyZSdzIHBlcmhhcHMgbm8g
d2F5IGZvcgo+ID4+IHVtb3VudC5uZnMgdG8ga25vdyB3aGV0aGVyIGl0IHNob3VsZCBzZW5kIHRo
ZSBVTU5UIHJlcXVlc3QuICBJZiB0aGUKPiA+PiBzZXJ2ZXIgaXMgc2xvdyBvciB1bnJlc3BvbnNp
dmUsIHRoYXQgZmlsZSBzeXN0ZW0gd29uJ3QgYmUgdW5tb3VudGVkCj4gPj4gdW50aWwgbG9uZyBh
ZnRlciB0aGUgdW1vdW50Lm5mcyBjb21tYW5kIGhhcyBleGl0ZWQuCj4gPj4KPiA+PiBUaGlzIHNo
b3VsZG4ndCBiZSBtdWNoIG9mIGEgYmlnIGRlYWwsIHNpbmNlIHRoZSBzZXJ2ZXIncyBybXRhYiBp
cwo+ID4+ICJvcm5hbWVudGFsIiBhY2NvcmRpbmcgdG8gdGhlIG1hbiBwYWdlLiAgTm8gb25lIHNo
b3VsZCByZWx5IG9uIGl0IGJlaW5nCj4gPj4gYWNjdXJhdGUuCj4gPj4KPiA+PiBBIHBvc3NpYmxl
IHdheSB0byBmaXggdGhpcyBpcyB0byBoYXZlIHRoZSBrZXJuZWwgc2VuZCB0aGUgVU1OVC4KPiA+
IEl0IG1ha2VzIHNlbnNlLCBidXQgaXQgZG9lc24ndCBzZWVtIHRvIHRyaWdnZXIgbXVjaCBpbnRl
cmVzdCA6KQo+ID4KPiA+IFNob3VsZCBJIG9wZW4gYSBidWcgc29tZXdoZXJlLCB0byBlbnN1cmUg
dGhlIGlzc3VlIHdvbid0IGJlIGZvcmdvdHRlbiA/Cj4gCj4gWW91IG1pZ2h0IGNvbnNpZGVyIGZp
bGluZyBhIGJ1ZyBpbiB0aGUgTkZTdjQgYnVnemlsbGEgb24gbGludXgtbmZzLm9yZy4KPiAKCjEp
IFdoYXQgZG9lcyB0aGlzIGhhdmUgdG8gZG8gd2l0aCBORlN2ND8KCjIpIEkgZG9uJ3QgaGF2ZSB0
byBkbyBsYXp5IHVtb3VudHMgaW4gb3JkZXIgdG8gY29uZnVzZSB1bW91bnQubmZzLgpDb25zaWRl
cgoKbW91bnQgLXQgbmZzIGZvbzovYmFyIC9tbnQxCm1vdW50IC0tYmluZCAvbW50MSAvbW50Mgp1
bW91bnQgL21udDEKdW1vdW50IC9tbnQyCgozKSBFdmVuIHRoZSBrZXJuZWwgZG9lc24ndCBrbm93
IHdoYXQgdG8gZG8gaW4gYWxsIGNhc2VzLCBiZWNhdXNlIGl0CmRvZXNuJ3Qga25vdyB3aGV0aGVy
IG9yIG5vdCBhIG1vdW50IHJwYyBjYWxsIHdhcyBzZW50IG9yIG5vdCBmb3IgZWFjaAptb3VudHBv
aW50IHRoYXQgeW91IGRvIGEgJ3Vtb3VudCAvbW50JyBvbi4gQ29uc2lkZXIgdGhlIGNhc2Ugd2hl
cmUgeW91CmRvIGEgY2xvbmUoQ0xPTkVfTkVXTlMpLCBhbmQgdGhlbiB0aGUgdXNlciBkb2VzICd1
bW91bnQgL21udCcgaW4gX29uZV8Kb2YgdGhvc2UgbmFtZXNwYWNlcy4KCklPVzogUGxlYXNlIGp1
c3QgYWNjZXB0IHRoYXQgdGhpcyBpcyBhIGZlYXR1cmUsIG5vdCBhIGJ1Zy4gTm9ib2R5CnByb21p
c2VkIHlvdSB0aGF0IHRoZSBtb3VudGQgc3RhdGlzdGljcyB3b3VsZCBiZSAxMDAlIGFjY3VyYXRl
LCBhbmQKd2UncmUgY2VydGFpbmx5IG5vdCBnb2luZyB0byB3YXN0ZSB0aW1lIHRyeWluZyB0byBt
YWtlIGl0IHNvLgoKVHJvbmQKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fCk5GU3Y0IG1haWxpbmcgbGlzdApORlN2NEBsaW51eC1uZnMub3JnCmh0dHA6Ly9s
aW51eC1uZnMub3JnL2NnaS1iaW4vbWFpbG1hbi9saXN0aW5mby9uZnN2NA==