Linux NFS development
 help / color / mirror / Atom feed
From: Karel Zak <kzak@redhat.com>
To: Neil Brown <neilb@suse.com>
Cc: util-linux@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: mount does not accurately identify existing NFS mounts, and shouldn't try.
Date: Fri, 30 Oct 2015 11:55:09 +0100	[thread overview]
Message-ID: <20151030105509.GG19508@ws.net.home> (raw)
In-Reply-To: <87twpnll5y.fsf@notabene.neil.brown.name>

On Mon, Oct 19, 2015 at 12:08:41PM +1100, Neil Brown wrote:
> 	/* Refuse the same filesystem on the same mount point */
> 	err = -EBUSY;
> 	if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb &&
> 	    path->mnt->mnt_root == path->dentry)
> 		goto unlock;
> 
> This is the *only* time that the kernel returns EBUSY for a "mount a new
> filesystem" request (remount can return EBUSY for other reasons I
> think).
> 
> So in the case where "mount" thinks it should check if the filesystem is
> already mounted and ignore the request if it is, the best thing it can
> do is to just try the mount and ignore any "EBUSY" error status - treat
> that the same as success.
> 
> So all that code for "is this the same mountpoint" can probably be
> discarded.

Well, we have many situations (another than mount -a) when you want to
know if the FS is mounted, but you have not permissions for mount(2)
or you don't want to try it (because mount(2) may trigger many another
things in userspace).

> Did I miss any important consideration there?

The problem is that the way between fstab entry and mount(2) is
sometimes pretty complex (mount.<type> helpers, loop devices,
UUID/LABEL translation, etc).

So, compare fstab with /proc/mounts is usually good compromise...

Your suggestion seems usable for mount -a, but it's one small use-case
(and for example systemd don't use "mount -a" during boot).

> Unfortunately this change could be awkward to implement as /sbin/mount
> decides whether to try the mount and (for NFS), /sbin/mount.nfs gives an
> error message if EBUSY is returned.  Would we need to pass a "noebusy"
> flag, but only if mount.nfs were willing to accept it....
> 
> Any suggestions?

We have kill(PID, 0) to detect if the PID is valid, you don't have to
parse all /proc. It would be nice to have the same for filesystems,
something like

    mount("/dev/sda1, "/mnt", "ext4", MS_NOMOUNT, NULL)

   Karel 

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

  reply	other threads:[~2015-10-30 10:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19  1:08 mount does not accurately identify existing NFS mounts, and shouldn't try Neil Brown
2015-10-30 10:55 ` Karel Zak [this message]
2015-10-30 22:46   ` Neil Brown

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=20151030105509.GG19508@ws.net.home \
    --to=kzak@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.com \
    --cc=util-linux@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox