Чи є якась практична різниця між використанням ln -sабо mount --bind?
Я хочу перенести деякі папки на інший розділ, не змінюючи їх налаштування демона, і цікавитись, який підхід я повинен застосувати.
Я вважаю за краще, ln -sоскільки це вимагає мінімальних налаштувань (без /etc/fstabмодифікацій), але, можливо, є причина, чому це не часто?
Відповіді:
Чорт візьми, да. Якщо Ви виконуєте команду, ln -sВи створюєте символічне посилання, яке є inode, що вказує на певний об'єкт файлової системи, тому символьні посилання можуть перетинати файлові системи, а жорсткі посилання не можуть: жорсткі посилання не мають власного inode.
Якщо ви монтуєте файлову систему за допомогою --bind, ви створюєте другу точку кріплення для пристрою або файлової системи.
Якщо ви передбачаєте символьне посилання як переспрямування, то передбачте --bindзмонтовану файлову систему як створення іншого шлюзу для даних.
Символьні посилання та кріплення кріплення - це зовсім інша бальна гра.
--bindКріплення здається трохи більш надійним для мене , і це , ймовірно, трохи швидше , ніж роботи з лінком. З іншого боку, немає серйозних недоліків у використанні символьної посилання, оскільки показник ефективності буде невеликим (якщо він взагалі існує).
Редагувати : Я думав про це, і хіт на продуктивність може бути трохи більшим, ніж я спочатку думав. Якщо у вас є програма, яка читає багато різних файлів, то кожен новий відкритий файл потребує додаткового читання. Деякі дослідження тут говорять про те, що моє припущення є правильним, тому якщо у вас запущений важкий додаток IO, розгляньте --bindможливість встановити над рішенням symlink.
Причина, по якій не прийнято, ймовірно , той факт , що символічна видно в ls, в той час як прив'язка змонтованого видно тільки при погляді на / Proc / монтує або / і т.д. / mtab (який є те , що команда монтування робить, якщо виконується без параметрів). Крім цього, я не думаю, що проблем є. Мені було б цікаво, якщо вони є.
Додавання : ще одна проблема ln -s, що стосується деяких програм, коли шлях буде відмежовано, він може спричинити непридатність програми, якщо "очікує", що певні елементи будуть у певних місцях.
mount, при посиланні без аргументів друкує вміст /etc/mtab, який має дещо іншу інформацію, ніж /proc/mounts. (Зокрема, /proc/mounts(посилання на /proc/self/mounts) завжди відображаються точки бачення, видимі для процесу його читання.)
Однією з великих відмінностей між ln -sмонтом і прив'язкою є те, що ви можете використовувати кріплення прив’язки для "модифікації" файлової системи, доступної лише для читання. Наприклад, якщо був встановлений компакт-диск /mnt/application, який ви хотіли замінити /mnt/application/badconfigfile.confправильною версією, ви можете зробити це:
mount -o bind /path/to/correct/file.conf /mnt/application/badconfigfile.conf
Не вдасться вплинути на ту саму зміну за допомогою символьного посилання, оскільки ви не можете змінити цільову файлову систему.
Це також може бути корисним, якщо ви поширили загальний набір програмного забезпечення через NFS (або якусь файлову систему кластерів), і ви хочете внести зміни, характерні для хоста в одній системі. Ви можете просто використовувати кріплення прив’язки до цільової системи, щоб замінити файли чи каталоги за необхідності.
Можна відзначити, що як наслідок прив’язки до кріплення, яке саме по собі є обов'язковим, тобто згодом відскоком, оригінальне прив'язування залишається неушкодженим, припускаючи, що все фізично залишається на зв’язку.
Тобто, якщо зв’язувати A до B і зв'язувати B до C, а потім прив'язувати D до B, C все одно буде пов'язаний з A. Це може бути те, що ви хочете, чи ні. Якщо бажає C слідувати за B, тоді перераховуйте, використовуючи ті самі цілі, тобто mount -o remount B Cвикористовуйте --rbindзамість цього. Немає --rebindваріанту.