From: Karel Zak <kzak@redhat.com>
To: Steve Dickson <SteveD@redhat.com>
Cc: Chuck Lever <chuck.lever@oracle.com>, linux-nfs@vger.kernel.org
Subject: Re: mount.nfs libmount support (v3)
Date: Tue, 22 Mar 2011 09:21:23 +0100 [thread overview]
Message-ID: <20110322082123.GA30453@nb.net.home> (raw)
In-Reply-To: <4D87A12A.60209@RedHat.com>
On Mon, Mar 21, 2011 at 03:04:10PM -0400, Steve Dickson wrote:
> 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
hmm..
> 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.
right
> 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?
That's simple, entries from mtab or /proc have always defined some
mount options (at least rw/ro). This heuristic is already used in
umount_main()
if (!mnt_context_is_lazy(cxt)) {
if (opts) {
....
} else
/* strange, no entry in mtab or /proc not mounted */
nfs_umount23(spec, "tcp,v3");
}
If I good understand the 'else nfs_umount23(spec, "tcp,v3")' should be
removed from the code. If I remove this line, then:
# umount.nfs /mnt/home
umount.nfs: /mnt/home: not found
There is also mnt_fs_is_kernel() to check that the FS description is
from /proc, maybe I can also add mnt_fs_is_mtab() to the API.
> 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.
Yep, the "umount.nfs server://foo" should be evaluated and converted
to the valid FS description by libmount (mnt_context_prepare_umount),
any other fallback solution is unnecessary.
It seems we need v4 of the patch...
Thanks for review!
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
next prev parent reply other threads:[~2011-03-22 8:21 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 ` mount.nfs libmount support (v3) Steve Dickson
2011-03-22 8:21 ` Karel Zak [this message]
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=20110322082123.GA30453@nb.net.home \
--to=kzak@redhat.com \
--cc=SteveD@redhat.com \
--cc=chuck.lever@oracle.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.