All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Dickson <SteveD@redhat.com>
To: Karel Zak <kzak@redhat.com>
Cc: Chuck Lever <chuck.lever@oracle.com>, linux-nfs@vger.kernel.org
Subject: Re: mount.nfs libmount support (v3)
Date: Mon, 21 Mar 2011 15:04:10 -0400	[thread overview]
Message-ID: <4D87A12A.60209@RedHat.com> (raw)
In-Reply-To: <1300111108-13137-1-git-send-email-kzak@redhat.com>

Hey Karel,

On 03/14/2011 09:58 AM, Karel Zak wrote:
> This is the third version of the mount.nfs with libmount support. The code
> depends on util-linux >= v2.19 (e.g. Fedora 15).
> 
> v3:
>   - call umount_error() on mount(2) error
> 
> v2:
>   - move nfs_umount_do_umnt() to network.c
>   - use union nfs_sockaddr
>   - add missing GPL address paragraph
>   - use abstract function the storing and retrieval mount options
>   - use "static const" for struct option
>   - use "strncmp() == 0" everywhere
> 
> 
Looking at unmounting a non-existent fs I get:

# umount.nfs /mnt/home
umount.nfs: remote share not in 'host:dir' format
umount.nfs: /mnt/home: not mounted
#
I took a quick look as to why that incorrect "remote share...." 
is message is being generated and why it wasn't in the
previous code.

The message is being generated because nfs_umount23() is
is passed an invalid devname ('/mnt/home' in my case).
The reason the message was not being generated before
is because nfs_umount23() was not called when the devname
did not exist in the mtab.

Now, I understand the umount(2) system call still has to
occur when the devname is not found in the mtab. This happen
the previous code because del_mtab() was called  (which calls 
umount(2)) even when the devname was not in the mtab.

I also notice that the libmount code does indeed  know the devname 
is not in the mtab. The lookup_umount_fs() call fails which is in 
the mnt_context_prepare_umount() call... But, rightly so, you continue 
to process the umount. Plus the umount(2) is done during the 
mnt_context_do_umount() call which ends up generating the correct
"not mounted" message.

So my question is, is there some why I can tell, using the libmount
API, that the fs was not in either /proc/mounts or /etc/mtab?

Basically I do not want to call nfs_umount23() but I do want
to call mnt_context_do_umount() when the file system is not
in the mtab, similar to how it worked in the previous code.

steved.


  parent reply	other threads:[~2011-03-21 19:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-14 13:58 mount.nfs libmount support (v3) Karel Zak
2011-03-14 13:58 ` [PATCH 1/2] mount: move generic functions to utils.c and network.c Karel Zak
2011-03-14 13:58 ` [PATCH 2/2] mount: add --enable-libmount-mount Karel Zak
2011-03-21 19:04 ` Steve Dickson [this message]
2011-03-22  8:21   ` mount.nfs libmount support (v3) Karel Zak
2011-04-06 17:03 ` Steve Dickson

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=4D87A12A.60209@RedHat.com \
    --to=steved@redhat.com \
    --cc=chuck.lever@oracle.com \
    --cc=kzak@redhat.com \
    --cc=linux-nfs@vger.kernel.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.