Як linux працює з символічними посиланнями?


11

Я маю на увазі, що відбувається, коли якийсь процес хоче прочитати симпосилання? Що відбувається, коли щось змінює симпосилання під час читання чи навіть запису?

Наприклад: у мене є 2 величезних схожих 100G файли /mnt/1і /mnt/2. /mnt/1доступний через симпосилання /home/user/file. Деяка програма Aпочинає читати /home/user/file. І через деякий час щось змінює посилання з /mnt/1на /mnt/2, але Aфайл все ще читає.

Чи кеширує програма абсолютний шлях?

Чи буде вона помилкою і помилкою, тому що симпосилання було змінено або воно спрацює нормально, наче нічого не сталося?

Чи відрізнятиметься він у випадку, якщо /home/user/fileвін підключений до блочного пристрою (наприклад, 2 реплікувані диски iscsi)?

Відповіді:


9

Символьне посилання вказує на ім’я реального файлу ( inode ) у файловій системі. Коли система вирішує це посилання для пошуку фактичного файлу та відкриває його, вона знаходить і використовує його вклад. У цей момент шлях, який ви використовували, щоб потрапити до файлу, не має значення. Те, що ОС не кешує, зчитується з файлу за його inode. Ви можете, наскільки я розумію, почати читати файл через жорстке посилання та видалити це жорстке посилання (доки файл все ще пов’язаний з іншого місця) , і це не спричинило б проблем, поки файл вирішений ( ім'я string-> inode).


4
Ви можете видалити ВСІ посилання на файл і продовжувати читати його, як тільки ви відкриєте його. Ось чому ви можете оновити пакети без перезавантаження, як це потрібно для Windows; тому що ви можете запустити виконуваний файл програми, навіть якщо він працює.
psusi

1
@psusi Я знаю, що дані та inode все ще є і просто не вказали ні на що більше, але як тільки файл буде видалений, система вільна перезаписати це місце на диску, правда? Отже, якщо файл занадто великий, щоб вміститися у кеш-файлі, як-от запитувані файли розміром 100 Гб, що станеться, якщо частина з них буде перезаписана до того, як ви досягнете кінця? Це не стосується критичних системних файлів, оскільки вони завантажуються в кеш і зберігаються там, але 100 ГБ є досить великими, що, на мою думку, це може викликати занепокоєння.
Кевін

2
Кевін, файли не видалялися з диска до останнього процесу, який використовує файл. Ви завжди можете знайти всі файли, які зараз використовуються в proc. Але ваша відповідь, здається, пояснила моє запитання. Дякую.
пік

2
Ця відповідь пропускає критичну точку, що символьне посилання містить ім'я цільового файлу.
Кіт Томпсон

6

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

Коли ви відкриєте симпосилання, ОС буде слідувати розташуванню, щоб знайти цільовий файл. Якщо ціль сама по собі є символьним посиланням, вона також слідкує за своїм розташуванням (1) (2), поки розташування не вкаже на файл, який не є символьним посиланням (назвемо це FinalFile ). Потім операційна система отримує инод в FinalFile (індексний дескриптор містить метадані , як зміни часу і має також покажчик на дані файлу). Нарешті відкривається вклад FinalFile . Відтепер процес використовує цей метод для читання / запису у файл. В результаті змінюється ім'я або шлях символьного посилання, видаляється символьне посилання, змінюється шлях або ім'я FinalFile або навіть видаляється FinalFile(3) не впливає на процес; він все ще читається з тієї ж inode.

У більшості випадків операції з файловими даними на симпосиланнях впливатимуть на FinalFile (наприклад, читання та запис на симпосилання буде читатися з / записувати в FinalFile ), але є винятки: readlink()системний виклик зчитує вміст самого посилання.

Операції з метаданими файлів (наприклад, перейменування або видалення) з іншого боку, як правило, впливатимуть на симпосилання. Але тут є і винятки: lstat()системний виклик схожий stat(), за винятком того, що він повертає інформацію про саме посилання, а не про FinalFile (2).


(1) Існує обмеження щодо кількості рівнів і речі стають дещо складнішими, якщо розташування в симпосилання є відносним шляхом.

(2) Прочитайте символьне посилання (7): символічна обробка посилання для отримання більш детальної інформації.man 7 symlink

(3) rmКоманда або unlink()системний виклик фізично не видаляють файл. Він видаляє запис каталогу, який вказує на вкладення файлу. Сам файл видаляється лише в тому випадку, якщо обидва: a) більше немає записів каталогів (жорстких посилань), які посилаються на його inode, і b) жоден процес не відкриває файл.


1

Це майже прозоро для Linux, і це набагато більше стосується файлової системи, яку ви використовуєте, ніж операційної системи.

Це не звичайний файл або дуже маленький файл, оскільки ви не можете створити працюючу символічну посилання в розділі VFAT, наприклад, просто скопіювавши сам символічне посилання на нього, оскільки він записується безпосередньо файловою системою.

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

Приклад:

Тест 1:

echo 'data' >file.txt

Це створить файл file.txt жорсткого посилання, що вказуватиме на сектори 10-20 * (* цифри лише для пояснення).

Тест 2:

А що робити, якщо?

ln file.txt file_2.txt

Це створило жорстке посилання file_2.txt, що вказує на сектори 10-20 (те саме на file.txt), тому якщо ви видалите file.txt, сектори 10-20 залишаються зарезервованими, і ви можете побачити дані всередині file_2.txt ... . (file.txt і file_2.txt обидва як оригінали)

Тест 3:

ln -s file.txt file_sym.txt 

Указує символічне посилання file_sym.txt на файл жорсткого посилання file.txt, тому при спробі отримати доступ до file_sym.txt ви побачите file.txt, але якщо ви видалите файл file.txt, файл_sym більше не знайде цілі.

Вони управляються файловою системою, наприклад модулями ext4 для linux (або якщо вона компільована на ядрі), неважливо, ви використовуєте Linux чи інший Unix.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.