Есть ли какие-либо недостатки в использовании mount --bind вместо символических ссылок?

Символьные ссылки имеют ограничения в отношении того, как функции похожи ls, mvи cpмогут работать с ними, потому что в отличие от команд, инициируемых оболочкой cd, такие функции не имеют информации о том, как пользователь получил доступ к каталогу относительно логического пути (см. Связанный пост ). Кажется, что использование этой mount --bindопции вместо этого может обойти это, предлагая расширенную функциональность и совместимость с samba и другими файловыми серверами, потому что подключенный каталог будет иметь два независимых физических пути вместо ссылки.

Я хотел бы заменить все мои символические ссылки ссылками, используя эту mount --bindопцию, но это означало бы монтирование более 150 точек в fstab. Есть ли какие-либо проблемы с производительностью, которые могут потенциально возникнуть из-за этого или любых других недостатков, которые я должен рассмотреть?

При mount --bindэтом дерево каталогов существует в двух (или более) местах в иерархии каталогов. Это может вызвать ряд проблем. Резервные копии и другие копии файлов выберут все копии. Становится трудно указать, что вы хотите скопировать файловую систему: в итоге вы скопируете файлы, смонтированные с привязкой, дважды. Поисковые запросы с find, grep -r, locateи т.д., будут проходить все копии, и так далее.

Вы не получите никакой «повышенной функциональности и совместимости» с bind mounts. Они похожи на любой другой каталог, который в большинстве случаев не желаемое поведение. Например, Samba по умолчанию предоставляет символические ссылки в качестве каталогов; нет ничего, что можно было бы получить с помощью привязки. С другой стороны, bind mounts могут быть полезны для представления иерархий каталогов по NFS.

У вас не будет проблем с производительностью bind mounts. То, что вы будете иметь, это головные боли администрации. У присоединяемых монтировок есть свои применения, такие как создание дерева каталогов, доступного из chroot, или предоставление каталога, скрытого точкой монтирования (это обычно временное использование во время перестройки структуры каталогов). Не используйте их, если у вас нет необходимости.

Только root может управлять привязкой. Они не могут быть перемещены обычными средствами; они фиксируют свое местоположение и каталоги предков.

Вообще говоря, если вы передаете символическую ссылку в команду, команда действует на саму ссылку, если она работает с файлами, и на цель ссылки, если она работает с содержимым файла. Это касается и каталогов. Это обычно правильно. Некоторые команды имеют опции для лакомств символических ссылок по- разному, например ls -L, cp -d, rsync -l. Что бы вы ни пытались сделать, гораздо более вероятно, что символические ссылки являются правильным инструментом, чем bind mounts, являющимся правильным инструментом.

В дополнение к тому, что @Gilles писал ранее, стоит отметить, что некоторые утилиты могут рассматривать каталог, подключенный по привязке , как отдельную файловую систему. Это может иметь последствия для производительности или функциональности, если программа больше не может предполагать, что один и тот же номер инода относится к одному и тому же файлу (чего не происходит, если они находятся в разных файловых системах), перемещение нельзя оптимизировать как ссылку на target-then-unlink-source и т. д.

Вы также должны захотеть использовать bind mounts вместо символических ссылок, когда вы полагаетесь на поддержку, которая может быть не всегда на месте (например, на внешний диск), и вы хотите быть уверены, что исходная структура каталогов на месте, даже если поддержка не удается или удаляется.

Например, если я хочу сохранить / var / tmp на SD-карте, я буду использовать привязку bind, поскольку некоторые программы ожидают, что / var / tmp будет действительным каталогом, даже если карта удалена.

Я попытался bind mount, чтобы обойти проблему установки некоторых пакетов с pacman(archlinux, подробнее об этом здесь ) в системе, где /var(а также /homeи /usr/local) были символические ссылки (между файловыми системами: SSD на SATA).

Сначала он выглядел великолепно, но, как указал Жиль, locateвсегда давал несколько результатов для одного файла, несмотря на PRUNE_BIND_MOUNTS = "yes"строку в /etc/updatedb.conf.

$ locate \*/findutils-4.4.2 | xargs ls -ldiog
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /SHARED/LOCALS/Manjaro/src/findutils-4.4.2
33816600 drwxr-xr-x 12 4096 Dec  3 00:05 /usr/local/src/findutils-4.4.2

Покопавшись немного дальше, я обнаружил, что более сложные крепления могут быть правильно обрезаны:

$ sudo mount --bind /SHARED/LOCALS/common/ /usr/local/common
$ findmnt | fgrep -n sdb
34:├─/SHARED/LOCALS                  /dev/sdb5           ext4           rw,relatime,data=ordered
35:│ └─/SHARED/LOCALS/Manjaro/common /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
36:├─/usr/local                      /dev/sdb5[/Manjaro] ext4            rw,relatime,data=ordered
37:│ └─/usr/local/common             /dev/sdb5[/common]  ext4            rw,relatime,data=ordered
38:├─/SHARED/HOMES                   /dev/sdb4           ext4            rw,relatime,data=ordered
39:├─/home                           /dev/sdb4[/Manjaro] ext4            rw,relatime,data=ordered
40:├─/SHARED/VARS                    /dev/sdb3           ext4            rw,relatime,data=ordered
41:├─/var                            /dev/sdb3[/Manjaro] ext4            rw,relatime,data=ordered
42:└─/opt                            /dev/sdb5[/opt]     ext4            rw,relatime,data=ordered

$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
Rebuilding bind_mount_paths:
Matching bind_mount_paths:
Skipping `/SHARED/LOCALS/Manjaro/common': bind mount
Skipping `/usr/local/common': bind mount

$ locate \*/mmedia
/SHARED/LOCALS/common/mmedia

Без опции PRUNE_BIND_MOUNT я бы получил 3 результата:

$ sudo sed -i '1 s/yes/no/' /etc/updatedb.conf 
$ sudo updatedb --debug-pruning 2>&1 >/dev/null | grep bind
prune_bind_mounts\000
$ locate \*/mmedia
/SHARED/LOCALS/Manjaro/common/mmedia
/SHARED/LOCALS/common/mmedia
/usr/local/common/mmedia
$ sudo sed -i '1 s/no/yes/' /etc/updatedb.conf 

Еще одна проблема с креплениями:

• grub-mkrelpath выдает неправильные пути, если / boot является bind mount

Конечно, можно вручную добавить привязки монтирования (точки монтирования или цели) в PRUNEPATHSin /etc/updatedb.conf.

Кроме того, mountpointи различные statкоманды или функции могут использоваться в инструментах для улучшения обхода файловой системы, как предложено здесь

Когда дело доходит до файловых привязок, они ведут себя ближе к жестким ссылкам, чем к символическим ссылкам. Это может иметь несколько неуловимые последствия, например:

# echo 1 > 1.txt
# touch 2.txt
# mount --bind 1.txt 2.txt
# cat 2.txt
1
# echo 1a > 1.txt
# cat 2.txt
1a

Пока все хорошо, но теперь посмотрим, сколько программ (редакторы, правильно написанные скрипты и т. Д.) Действительно изменяют файлы:

# echo 1new > 1new.txt
# mv 1new.txt 1.txt
# cat 1.txt
1new
# cat 2.txt
1a

Если 2.txtбы это была символическая ссылка, 1.txtто последняя команда выдала бы результат 1new, чего, вероятно, и следовало ожидать.

Это может вызвать некоторые тонкие проблемы: в systemd я использовал, BindReadOnlyPaths=чтобы конкретный сервис использовал resolv.confфайл, отличный от остальной системы, но это оказалось странным и странным и трудно диагностировать, потому resolvconfчто он заменил бы исходный файл за Сервис вернулся.