Skip to contentSkip to conversation

mount existing tmpfs mounts a new tmpfs

DISCUSSION Phillip Susi 6 participants 9 messages Jun 22, 2015 – Jun 23, 2015 1 message not in the archive

Subsystems (2)
VFS Util-Linux package
lore
Share & tools
lore

Phillip Susi

author
#0 lore raw

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJVh2xSAAoJENRVrw2cjl5RnisH/1wvRqqlgckjp1sRdo/zGfHX Wpw5vIYxefXvKrQsyI64DMLV6MNNnFdGNIj8QxnBJwMpzFq0+p08u0AWmThNg35Q H1as8PA8+RkM7e7vzPXFId7QMjL+Lx09TE4Tg0y6HERF834FnL3QDwYna5AcJbVg wvADB7CTEAK3SHv1F1HHVOcKb6DFw0ur/JIM93+P6rohu7jhUOWq+SVcDNZgA/JQ dzEzBgFv1+yJPHYP4J8lKTddq+TOGzhamlusfz/6feSKzyvFKSxaPWDrLTNk5hu3 dj3bHoiWlGB7meo3NCDqKLH6nLeOUhlXgaGh0vm72fwM7Ip4DkO0Ovy4dloxokA= =Umj1
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in

#1 lore raw

[tom@localhost ~]$ cat /etc/fstab
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
[tom@localhost ~]$ sudo mount /run
mount: can't find /run in /etc/fstab

Again, Arch Linux ; )

Quoted 11 lines · Phillip Susi

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

Quoted 10 lines

iQEcBAEBCgAGBQJVh2xSAAoJENRVrw2cjl5RnisH/1wvRqqlgckjp1sRdo/zGfHX Wpw5vIYxefXvKrQsyI64DMLV6MNNnFdGNIj8QxnBJwMpzFq0+p08u0AWmThNg35Q H1as8PA8+RkM7e7vzPXFId7QMjL+Lx09TE4Tg0y6HERF834FnL3QDwYna5AcJbVg wvADB7CTEAK3SHv1F1HHVOcKb6DFw0ur/JIM93+P6rohu7jhUOWq+SVcDNZgA/JQ dzEzBgFv1+yJPHYP4J8lKTddq+TOGzhamlusfz/6feSKzyvFKSxaPWDrLTNk5hu3 dj3bHoiWlGB7meo3NCDqKLH6nLeOUhlXgaGh0vm72fwM7Ip4DkO0Ovy4dloxokA= =Umj1
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in

--
To unsubscribe from this list: send the line "unsubscribe util-linux" in

maintainer
#2 lore raw
In reply to Phillip Susi
Quoted 4 lines · Phillip Susi

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

We usually don't play any policy games in userspace (exception is mount -a). If it's supported by kernel then it's correct behaviour. And IMHO it's really correct behaviour because it creates a *new* filesystem.

Karel

Signature · 4 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
#3 lore raw
Quoted 10 lines · Karel Zak
Quoted 4 lines · Phillip Susi

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

We usually don't play any policy games in userspace (exception is mount -a). If it's supported by kernel then it's correct behaviour. And IMHO it's really correct behaviour because it creates a *new* filesystem.

Is it really the kernel who does not mount again other filesystems? For me tmpfs behavior looks different for no reason:

$ cat /etc/fstab
/dev/sda1                  /boot       ext2   defaults  0 0
glaukos:/exports/opt/intel /opt/intel  nfs    defaults  0 0
proc                       /tmp/proc   proc   defaults  0 0
none                       /tmp/tmpfs  tmpfs  defaults  0 0

When everything is mounted already I get:

$ mount /boot
mount: /dev/sda1 is already mounted or /boot busy
       /dev/sda1 is already mounted on /boot
$ mount /opt/intel/
mount.nfs: /opt/intel is busy or already mounted
$ 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

Only tmpfs would be mounted again and again

$ mount /tmp/tmpfs/
$ mount | grep /tmp/tmpfs
none on /tmp/tmpfs type tmpfs (rw,relatime)
none on /tmp/tmpfs type tmpfs (rw,relatime)

cu,
Rudi

maintainer
#4 lore raw
Quoted 7 lines · Ruediger Meier
Quoted 6 lines · Karel Zak
Quoted 4 lines · Phillip Susi

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

Quoted 6 lines
Quoted 4 lines

We usually don't play any policy games in userspace (exception is mount -a). If it's supported by kernel then it's correct behaviour. And IMHO it's really correct behaviour because it creates a *new* filesystem.

Is it really the kernel who does not mount again other filesystems?

Sure, use strace to see more:

Quoted 8 lines

For me tmpfs behavior looks different for no reason:

$ cat /etc/fstab
/dev/sda1                  /boot       ext2   defaults  0 0
glaukos:/exports/opt/intel /opt/intel  nfs    defaults  0 0
proc                       /tmp/proc   proc   defaults  0 0
none                       /tmp/tmpfs  tmpfs  defaults  0 0
Quoted 5 lines

When everything is mounted already I get:

$ mount /boot
mount: /dev/sda1 is already mounted or /boot busy
       /dev/sda1 is already mounted on /boot
# strace -e mount mount /boot
mount("/dev/sda2", "/boot", "ext4", MS_MGC_VAL, NULL) = -1 EBUSY
(Device or resource busy)
Quoted 2 lines
$ mount /opt/intel/
mount.nfs: /opt/intel is busy or already mounted
# strace -fe mount mount /mnt/backup
Process 27674 attached
[pid 27674] mount("sr.net.home:/mnt/store/backup", "/mnt/backup",
"nfs", 0, "vers=4.2,addr=192.168.111.1,clie"...) = -1 EPROTONOSUPPORT
(Protocol not supported)
[pid 27674] mount("sr.net.home:/mnt/store/backup", "/mnt/backup",
"nfs", 0, "vers=4.1,addr=192.168.111.1,clie"...) = -1 EPROTONOSUPPORT
(Protocol not supported)
[pid 27674] mount("sr.net.home:/mnt/store/backup", "/mnt/backup",
"nfs", 0, "vers=4.0,addr=192.168.111.1,clie"...) = -1 EBUSY (Device or
resource busy)
Quoted 4 lines
$ 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)

Karel

Signature · 4 lines
 Karel Zak  <[email protected]>
 http://karelzak.blogspot.com
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
author
#5 lore raw

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?

Quoted 3 lines · Karel Zak
# 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.

Quoted 8 lines
Quoted 4 lines
$ 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

A message that is not in the archive (sent off-list or not yet received): 558857AF.40707-GeWIH/[email protected]

#7 lore raw

Isn't it just the same case as when you mount something else to a mountpoint being used? Like if /dev/sda1 is already mounted to /boot, and it has an entry in fstab, then you probably can't mount /dev/sda1 /boot or mount /boot, but you can still mount sda2 or so to /boot. And since each tmpfs is like a new filesystem, so isn't it pretty consistent?

Though I have no idea why wouldn't in Debian tell you it's not in fstab. Who knows what patches have they applied.

Quoted 48 lines · Phil Susi

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?

Quoted 4 lines · Karel Zak
# 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.

Quoted 9 lines
Quoted 4 lines
$ 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.

Quoted 2 lines

--
To unsubscribe from this list: send the line "unsubscribe util-linux" in

--
To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

author
#8 lore raw
In reply to Karel Zak
Quoted 10 lines · Karel Zak
Quoted 4 lines · Phillip Susi

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

We usually don't play any policy games in userspace (exception is mount -a). If it's supported by kernel then it's correct behaviour. And IMHO it's really correct behaviour because it creates a *new* filesystem.

The single argument form of mount isn't *supposed* to create a new filesystem. It is supposed to mount one described by /etc/fstab if it is not already mounted. It should not be looking up /proc/mounts and treating what it finds there as if it was an /etc/fstab entry, and then blindly trying to remount the already mounted filesystem. Only the two argument form of mount should do this.

--
To unsubscribe from this list: send the line "unsubscribe util-linux" in

#9 lore raw
In reply to Phillip Susi
Quoted 4 lines · Phillip Susi

Forwarding this from debian bug #772419: Run mount /run, and it mounts a new tmpfs over top of the existing one in /run ( even if /run isn't listed in /etc/fstab ), hiding the existing files. It should say that it is already mounted.

Devuan Jessie, mount 2.26.2-6+devuan1, only says that /run is not in /etc/fstab unless I use:
mount -t tmpfs tmpfs /run

The "filesystem mounted or mountpoint busy" stuff should be from getting errno == EBUSY; this won't happen if you use a virtual filesystem that supports multiple instances.

*As far as I know*, the only way mount with a single argument is able to determine the correct filesystem or mountpoint without reading /etc/fstab is if you add the "remount" option.

HTH,
Isaac Dunham
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in