/devвариант tmpfs (devtmpfs) Ядро заполняет его узлами устройства, но содержимое является гибким, и демон пользовательского пространства udev настраивает их разрешения, создает символические ссылки (например, / dev / disk / by- *) и т. Д.
Вы хотите связать существующий экземпляр, чтобы перенести изменения, сделанные udev. Попытка смонтировать новый экземпляр выдаст свежие tmpfs только с предоставленными ядром узлами, но без ссылок udev.Царапины, что, по- видимому, нынешние ядра действительно лечить devtmpfs в одной инстанции, в отличие от обычных TMPFS. То есть, монтируя его дважды, вы оба раза получите одно и то же содержимое.
Тем не менее, я думаю, что те же рассуждения все еще применимы: люди рекомендуют связывать / dev, потому что они делают то же самое предположение, что я делал (правильно или нет), что он работает так же, как традиционные tmpfs.
Более того, до недавнего времени / dev был на самом деле традиционным tmpfs со всем, что в нем было создано пользовательским пространством (udev или аналогичным). При работе с системами до добавления devtmpfs привязка / dev все еще была необходима.
/procи /sysполностью виртуальные файловые системы (procfs и sysfs). Ядро контролирует все операции и определяет жесткую структуру.
Несколько монтирований procfs или sysfs в одних и тех же пространствах имен полностью идентичны - все они ссылаются на один и тот же экземпляр файловой системы. Поэтому нет никакой разницы между монтированием нового экземпляра для обычного chroot и связыванием существующего.
(Различия начинают появляться, когда вы работаете с контейнерами, например, с пространствами имен процессов или сетевыми пространствами имен. Монтирование нового экземпляра procfs в контейнере даст ограниченное представление только о его собственных процессах; привязка procfs хоста позволит контейнеру видеть все процессы. )