/dev
is a tmpfs variant (devtmpfs). The kernel populates it with device nodes, but the contents are flexible, and udev userspace daemon adjusts their permissions, creates symlinks (e.g. /dev/disk/by-*), etc.
You want to bind the existing instance in order to carry over the changes made by udev. Trying to mount a new instance would give a fresh tmpfs with just kernel-provided nodes, but without udev links. Scratch that, apparently the current kernels do treat devtmpfs as single-instance, as opposed to ordinary tmpfs. That is, mounting it twice will still give you the same contents both times.
However, I think the same reasoning still applies: people recommend binding /dev because they make the same assumption that I've been making (whether correctly or not) that it works the same way as a traditional tmpfs.
Moreover, until fairly recently, /dev was in fact a traditional tmpfs with everything in it created by userspace (udev or similar). When working with systems before the addition of devtmpfs, binding /dev was still a necessity.
/proc
and /sys
are fully virtual filesystems (procfs and sysfs). The kernel controls all operations and defines a rigid structure.
Multiple procfs or sysfs mounts within the same namespaces are completely identical – all of them refer to the same instance of the filesystem. Therefore there is no difference between mounting a new instance for an ordinary chroot and binding an existing one.
(Differences begin to appear when you work with containers, e.g. process namespaces or network namespaces. Mounting a new procfs instance within a container would give a limited view of its own processes only; binding the host's procfs would allow the container to see all processes.)
So with
mount -t
and with regard to mounting /dev, you said this would give a fresh tmpfs... does that mean its a clone in this case? - is that true in general formount -t
(i.e. it creates a clone)? – code_fodder – 2018-10-01T13:23:45.550It's always true for tmpfs (which is multi-instance by design), it's apparently not true for devtmpfs (special case), and it may or may not be true for various other virtual filesystems (i.e. those that aren't stored on disk), usually depending on what felt right at the time of development. (devpts at /dev/pts is interesting because it used to have an explicit -o new_instance option, and the default behavior changed recently.) – user1686 – 2018-10-01T13:27:34.123