From: Phil Susi <psusi@ubuntu.com>
To: Karel Zak <kzak@redhat.com>, Ruediger Meier <ruediger.meier@ga-group.nl>
Cc: util-linux <util-linux@vger.kernel.org>, linux-fsdevel@vger.kernel.org
Subject: Re: mount existing tmpfs mounts a new tmpfs
Date: Mon, 22 Jun 2015 14:45:03 -0400 [thread overview]
Message-ID: <558857AF.40707@ubuntu.com> (raw)
In-Reply-To: <20150622141551.GK1992@ws.net.home>
Ccing linux-fsdevel. To catch up if you are just tuning in, the
original problem is that "mount /run" mounts a new instance of tmpfs
over top of the existing one, hiding the existing files, rather than
reporting that it is already mounted. The question is, is this a bug in
mount, or the kernel?
On 6/22/2015 10:15 AM, Karel Zak wrote:
> # strace -e mount mount /boot
> mount("/dev/sda2", "/boot", "ext4", MS_MGC_VAL, NULL) = -1 EBUSY
> (Device or resource busy)
Why on earth is the kernel still returning EBUSY here? It *does*
support mounting the same block device multiple times these days so it
should not be doing this. It looks like it has some check to see if
that device is already mounted somewhere in the current filesystem
namespace and returns EBUSY if it is, otherwise, just bind mounts the
existing mount if it is mounted in a different filesystem namespace.
Not only does this check seem pointless, but it simply makes no sense at
all for any filesystem that isn't backed by a block device, such as
tmpfs, procfs, network filesystems, etc.
>> $ mount /tmp/proc/
>> mount: proc is already mounted or /tmp/proc busy
>> proc is already mounted on /proc
>> proc is already mounted on /tmp/proc
>
> strace -e mount mount -t proc none /proc
> mount("none", "/proc", "proc", MS_MGC_VAL, NULL) = -1 EBUSY (Device or
> resource busy)
Now *what* is this nonsense? You can mount proc any time, anywhere you
want to. This EBUSY seems to be a special case hack that you only get
if you try to mount procfs inside procfs. You can mount any other fs
over top of /proc, and you can mount /proc over top of any other fs.
Why the one off check for mounting proc on top of proc? And is tmpfs
and any other virtual filesystem supposed to do this same check?
What if you really *want* to mount a new tmpfs over the old one? The
kernel shouldn't be denying that request ( really, same goes for proc ).
It therefore, should be the responsibility of mount ( single argument
form ) to notice when you have requested mounting of an already mounted
filesystem listed in /fstab, and it certainly should not be treating
/etc/mtab as if it were /etc/fstab and trying to mount the same thing a
second time; the single argument form of mount should only consult
fstab, not mtab too.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
next parent reply other threads:[~2015-06-22 18:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <55876C53.7030505@ubuntu.com>
[not found] ` <20150622082008.GH1992@ws.net.home>
[not found] ` <201506221455.46930.ruediger.meier@ga-group.nl>
[not found] ` <20150622141551.GK1992@ws.net.home>
2015-06-22 18:45 ` Phil Susi [this message]
[not found] ` <558857AF.40707-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>
2015-06-23 9:44 ` mount existing tmpfs mounts a new tmpfs Tom Yan
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=558857AF.40707@ubuntu.com \
--to=psusi@ubuntu.com \
--cc=kzak@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=ruediger.meier@ga-group.nl \
--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;
as well as URLs for NNTP newsgroup(s).