Есть ли практическая разница между использованием ln -s или mount --bind?
Я хочу переместить некоторые папки в другой раздел, не меняя их настройки демона, и задаюсь вопросом, какой подход мне следует предпринять.
я предпочитаю ln -s так как требует минимальной настройки (нет /etc/fstab модификации), но, может быть, есть причина, по которой это не распространено?
Да, черт возьми. Если вы выполните ln -s вы создаете символическую ссылку, которая является индекс указывает на определенный объект файловой системы, поэтому символические ссылки могут перемещаться по файловым системам, а жесткие ссылки не могут: жесткие ссылки не имеют своего собственного индексного дескриптора.
Если вы монтируете файловую систему с --bind, вы создаете второй точка крепления для устройства или файловой системы.
Если вы представляете символическую ссылку как перенаправление, тогда представьте себе --bind смонтированная файловая система как создание еще одного шлюза к данным.
Символические ссылки и привязки - это совсем другое дело.
В --bind mount мне кажется более надежным и, вероятно, немного быстрее, чем работа с символической ссылкой. С другой стороны, у использования символической ссылки нет серьезных недостатков, так как снижение производительности будет небольшим (если оно вообще существует).
редактировать: Я думал об этом, и удар по производительности может быть немного больше, чем я думал изначально. Если у вас есть приложение, которое читает много разных файлов, то для каждого нового открываемого файла потребуется дополнительное чтение. Некоторые исследования Вот предполагает, что мое предположение верно, поэтому, если у вас работает приложение с интенсивным вводом-выводом, рассмотрите --bind возможность монтировать над решением для символической ссылки.
Причина, по которой это нечасто, вероятно, заключается в том, что символическая ссылка видна в ls, тогда как привязка монтирования видна только при просмотре / proc / mounts или / etc / mtab (что и делает команда mount, если она выполняется без параметров). Кроме этого, я не думаю, что есть какие-то проблемы. Хотя мне было бы интересно, если они есть.
Дополнение: еще одна проблема с ln -s в том, что для некоторых приложений разыменование пути может привести к блокировке приложения, если оно «ожидает» определенных элементов в определенных местах.
Одно из больших различий между ln -s а bind mount - это то, что вы можете использовать bind mount для «модификации» файловой системы, доступной только для чтения. Например, если на /mnt/application, и вы хотели заменить /mnt/application/badconfigfile.conf с правильной версией вы можете сделать это:
mount -o bind /path/to/correct/file.conf /mnt/application/badconfigfile.conf
Невозможно повлиять на то же изменение с помощью символической ссылки, потому что вы не можете изменить целевую файловую систему.
Это также может быть полезно, если вы распространили общий набор программного обеспечения через NFS (или какую-то кластерную файловую систему) и хотите внести изменения для конкретного хоста в одной системе. Вы можете просто использовать привязку монтирования в целевой системе, чтобы при необходимости переопределить файлы или каталоги.
Практическая разница # 1 между ln -s и mount --bind для меня:
vsftpd не позволяет просматривать каталог по символической ссылке, но позволяет при установке.
Я не знаю, какой демон вы используете, но он может вести себя аналогичным образом.
Можно отметить, что в результате привязки к монтированию, которое само по себе является привязкой, которая позже отскакивает, исходная привязка остается нетронутой, если все физически остается подключенным.
То есть, если привязать A к B и связать B с C, а затем привязать D к B, C все равно будет привязан к A. Это может быть то, что вы хотите, или нет. Если кто-то желает, чтобы C следовал за B, то снова садитесь, используя те же цели, т.е. mount -o remount B C, или используйте --rbind вместо. Здесь нет --rebind вариант.