Статья Debian. Шпаргалка сисадмина. Симлинки и хардлинки призвана пролить свет на понятия жестких и мягких ссылок, а также рассказать про индексные дескрипторы, которые лежат в основе.
Если вам интересна тематика Debian и связанных с ним приложений, рекомендую обратиться к тегу Debian на моем блоге.
Содержание
Debian. Шпаргалка сисадмина. Симлинки и хардлинки
Начнем с самого главного.
Inode
Попытки разобраться в принципах работы файловой системы натолкнут вас на понятие inode (или индексный дескриптор). Эта структура хранит метаданные об объектах файловой системы (будь то файлы, каталоги или что-то другое). Метаданные предоставляют информацию о размере файла, его владельце, правах доступа, и многом другом, кроме имени.
Ext4 выделяет фиксированное значение inodes при создании файловой системы, которое приблизительно составляет 1% от размера тома. Из этого сразу следует, что на конкретном томе вы сможете создать ограниченное количество файлов/каталогов, даже если свободного места будет предостаточно – большое количество мелких файлов может просто сожрать все доступные inodes.
Увидеть номер inode файла или каталога можно всем знакомой командой ls с ключом -i:
|
1 |
ls -ilh |
|
1 2 |
1438990 -rw-r--r-- 1 root root 40K Май 29 2016 postconf.output 1438986 -rw-r--r-- 1 root root 0 Фев 14 19:34 test01.file.orig |
Первая цифра и есть номер индексного дескриптора.
Посмотреть сводную информацию по inodes на каждом логическом томе можно командой df также с ключом -i (вывод команды сокращен):
|
1 |
df -ih |
|
1 2 3 |
Файловая система Iнодов IИспользовано IСвободно IИспользовано% Cмонтировано в /dev/sdc5 2,0M 34 2,0M 1% /home /dev/sde5 2,0M 16 2,0M 1% /tmp |
Если нужно знать какой каталог сожрал больше всего inodes (другими словами в каком каталоге больше всего объектов), вы можете узнать это командой 1 (вывод сокращен):
|
1 |
find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n |
|
1 2 3 4 5 6 |
... 120 /sbin 132 /lib/x86_64-linux-gnu 161 /etc 208 /boot/grub 520 /etc/ssl/certs |
А теперь рассмотрим жесткие ссылки.
Жесткие ссылки
Жесткую ссылку на файл можно создать командой:
|
1 |
ln largefile largefilehardlink |
Первым делом в статье я рассказывал про понятие inode и это было не просто так. Давайте посмотрим вывод команды ls:
|
1 |
ls -lhi |
|
1 2 |
1838771 -rw-r--r-- 2 bq bq 4 июн 26 11:52 textfile 1838771 -rw-r--r-- 2 bq bq 4 июн 26 11:52 textfilehardlink |
Бросается в глаза тот факт, что inode у файла и его жесткой ссылки одинаковые! То есть, по сути, это один и тот же объект с точки зрения файловой системы и жесткая ссылка просто указывает на индексный дескриптор.
Cразу же можно сделать несколько выводов. Во-первых, при перемещении файла его жесткая ссылка продолжит работать. Во-вторых, жесткие ссылки можно создавать на файлы только в пределах границ одной файловой системы, поскольку в противном случае inodes не будут уникальны.
Есть ещё одна очень интересная особенность у жестких ссылок и я хочу её продемонстрировать. Для этого давайте удалим исходный файл:
|
1 |
rm textfile |
После этого, проверив работоспособность оставшейся “осиротевшей” жесткой ссылки вы обнаружите, что она осталась работоспособной! То есть, данные останутся доступны до тех пор, пока не будет удален сам файл и все его жесткие ссылки.
Можно пойти ещё дальше и сделать вывод, что сам файл и есть жесткая ссылка на данные, располагающиеся на запоминающем устройства. Это легко подтверждается выводом команды ls (на всякий случай продублирую его ещё разок):
|
1 2 |
1838771 -rw-r--r-- 2 bq bq 4 июн 26 11:52 textfile 1838771 -rw-r--r-- 2 bq bq 4 июн 26 11:52 textfilehardlink |
Обратите внимание на цифру, выделенную жирным шрифтом. Она обозначает количество жестких ссылок на файл.
Ну а теперь об ограничениях – создать жесткую ссылку на каталог у вас не получится, иначе возникает потенциальная возможность создания зацикленных указателей (подкаталог будет иметь жесткую ссылку на своего родителя).
Мягкие ссылки
Мягкие ссылки (симлинки, символические ссылки) создаются все той же утилитой, но с дополнительным ключом:
|
1 |
ln -s simplefile simplefilesymlink |
Если сейчас мы посмотрим на индексные дескрипторы файла и его симлинка:
|
1 2 |
1838773 -rw-r--r-- 1 bq bq 4 июн 26 13:49 simplefile 1838772 lrwxrwxrwx 1 bq bq 10 июн 26 13:49 simplefilesymlink -> simplefile |
… то увидим, что они отличаются. Другими словами, для файловой системы это абсолютно разные объекты и симлинк просто содержит информацию о пути к файлу. Отсюда можно сделать вывод, что при перемещении файла симлинк на него окажется в “подвешенном” состоянии, то есть работать перестанет. То же самое случится и при удалении исходного файла.
Но если симлинк – это отдельный объект файловой системы, то мы сразу избавляемся от массы ограничений. Например вполне можно создать симлинк на файл за границей текущей файловой системы, ведь мы больше не ограничены индексным дескриптором. Также никто не запрещает создать симлинк на каталог.
Вот и все особенности.
