All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: David Mathog <mathog-7GExONQZ6ZKVc3sceRu5cw@public.gmane.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: nfs-utils, umount -l, and unmount requests
Date: Fri, 21 Nov 2008 06:08:29 -0500	[thread overview]
Message-ID: <492696AD.8040905@RedHat.com> (raw)
In-Reply-To: <E1L2wsc-0004Rs-2I-Mlb+9xX7RBA8OKIjkCRLjtKIQNXEaThN@public.gmane.org>

David Mathog wrote:
> 
> 	if (mc) {
> 		if (!lazy && strcmp(mc->m.mnt_type, "nfs4") != 0)
> 			/* We ignore the error from do_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!
> 			 */
> 			do_nfs_umount23(mc->m.mnt_fsname, mc->m.mnt_opts);
> 		ret = del_mtab(mc->m.mnt_fsname, mc->m.mnt_dir);
> 	} else if (*spec != '/') {
> 		if (!lazy)
> 			ret = do_nfs_umount23(spec, "tcp,v3");
> 	} else
> 		ret = del_mtab(NULL, spec);
> 	return ret;
> 
> Removing the first "!lazy &&" resolved my immediate problem.  What I
> don't understand is why it, and the latter "!lazy", were there in
> the first place. 
To quote from the umount(8) man page:
 
       -l     Lazy unmount. Detach the filesystem from the filesystem  hierar-

              chy now, and cleanup all references to the filesystem as soon as

              it is not busy anymore.  (Requires kernel 2.4.11 or later.)

Which means in an NFS context that no RPC calls (i.e. call to the server)
can be made that could possibility hang 


> The do_nfs_umount23() routine seems to be relatively
> harmless, it either sends the message or it doesn't, but either way it
> doesn't seem to do anything to the mount information on the local node.
> So why is it not run if "-l" (lazy) is set?
Take a closer look... nfs_call_umount() makes a clnt_call() which 
would hang if the server is down, which is the reason its not called. 

I hope this helps....

steved.

  parent reply	other threads:[~2008-11-21 11:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-19 23:54 nfs-utils, umount -l, and unmount requests David Mathog
     [not found] ` <E1L2wsc-0004Rs-2I-Mlb+9xX7RBA8OKIjkCRLjtKIQNXEaThN@public.gmane.org>
2008-11-21 11:08   ` Steve Dickson [this message]
     [not found]     ` <492696AD.8040905-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2008-11-21 14:59       ` Chuck Lever
  -- strict thread matches above, loose matches on Subject: below --
2008-11-21 16:58 David Mathog
     [not found] ` <E1L3ZKo-0005DO-74-Mlb+9xX7RBA8OKIjkCRLjtKIQNXEaThN@public.gmane.org>
2008-11-21 17:43   ` Chuck Lever

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=492696AD.8040905@RedHat.com \
    --to=steved@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=mathog-7GExONQZ6ZKVc3sceRu5cw@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.