Чи є недоліки використання mount -bind в якості заміни символічних посилань?

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

Я хотів би замінити всі мої символічні посилання на посилання за допомогою mount --bindпараметра, але це означатиме встановлення понад 150 балів у fstab. Чи є якісь проблеми щодо ефективності, які потенційно можуть виникнути внаслідок цього чи будь-яких інших недоліків, які я повинен врахувати?

З mount --bind, дерево каталогів існує в двох (або більше) місцях в ієрархії каталогів. Це може спричинити ряд проблем. Резервні копії та інші копії файлів виберуть усі копії. Важко вказати, що ви хочете скопіювати файлову систему: ви в кінцевому підсумку скопіюєте файли, встановлені під прив’язку, двічі. Пошукові запити з find, grep -r, locateі т.д., буде проходити всі копії, і так далі.

Ви не отримаєте жодної «підвищеної функціональності та сумісності» із кріпленнями для прив’язки. Вони схожі на будь-який інший каталог, в якому більшість часу не бажана поведінка. Наприклад, Samba виставляє символьні посилання як каталоги за замовчуванням; нічого не можна отримати, використовуючи кріплення для прив’язки. З іншого боку, прив'язка кріплення може бути корисною для викриття ієрархій каталогів над NFS.

У вас не виникне жодних проблем із продуктивністю із кріпленнями прив’язки. Що у вас виникне - це головний біль у адміністрації. Встановлення прив'язки використовує такі можливості, як зробити дерево каталогів доступним через chroot або викрити каталог, прихований точкою монтажу (зазвичай це тимчасове використання під час перестановки структури каталогів). Не використовуйте їх, якщо у вас немає потреби.

Лише корінь може маніпулювати прив'язуванням кріплення. Їх неможливо перемістити звичайними засобами; вони фіксують своє місцезнаходження та каталоги предків.

Взагалі кажучи, якщо ви передаєте символьну посилання команді, команда діє як на саме посилання, якщо воно працює з файлами, так і на цільове посилання, якщо воно працює над вмістом файлу. Це стосується і каталогів. Зазвичай це правильна річ. Деякі команди мають опції для лікування символічних посилань по- різному, наприклад ls -L, cp -d, rsync -l. Що б ви не намагалися зробити, набагато ймовірніше, що символьні посилання є правильним інструментом, ніж прив'язувати кріплення як правильний інструмент.

На додаток до того, що @Gilles писав раніше, варто зазначити, що деякі утиліти можуть вважати каталог, встановлений для прив'язки, окремою файловою системою. Це може мати наслідки для продуктивності чи функціональності, якщо програма більше не може вважати, що одне і те ж число inode відноситься до одного файлу (чого немає, якщо вони є в різних файлових системах), переміщення не може бути оптимізовано як link-at- target-then-unlink-source тощо.

Ви також повинні використовувати прив'язування кріплення замість символьних посилань, коли ви покладаєтесь на підтримку, яка не завжди може бути на місці (наприклад, зовнішній диск), і ви хочете бути впевнені, що оригінальна структура каталогу є на місці, навіть якщо підтримка виходить з ладу або видаляється.

Наприклад, якщо я хочу зберегти / var / tmp на sd-картці, я використовуватиму прив’язку для прив’язки, оскільки деякі програми очікують, що / var / tmp буде дійсним каталогом, навіть якщо картку вилучено.

Я спробував прив’язати 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 є прив'язкою

Звичайно, можна вручну додати прив'язку монтування (mounpoint або цільові) , щоб PRUNEPATHSв /etc/updatedb.conf.

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