Индексные дескрипторы файлов
Погрузимся немного в особенности организации хранения файлов в файловых системах UNIX-подобных операционных систем и, в частности, Linux. Начнем с описания файла, который технически состоит из трех частей, хранящихся отдельно друг от друга.
Первая часть — имя файла
Имя вместе с идентификатором индексного дескриптора (inode) файла хранится в каталоге, к которому относится файл. Каталог — это файл специального типа с таблицей имен файлов и их номеров inode.
Посмотреть содержимое каталога можно командой ls, но, чтобы она отображала содержимое самого каталога, а не метаданных, запустите ее с таким набором параметров:
# ls -1ia /var/log | head
352 .
267 ..
112716 ahttpd
1905346 alterator-net-iptables
114533 audit
5842784 btmp
5842785 btmp.1.xz
75955 chrony
3025653 clamav
259603 cups
Вторая часть — метаданные файла
В них хранятся режимы доступа к файлу, информация о владельце, даты создания и изменения. Посмотреть содержание метаданных файла можно командой stat:
# stat /etc/passwd
Файл: /etc/passwd
Размер: 3847 Блоков: 8 Блок В/В: 4096 обычный файл
Device: 0,28 Inode: 5033772 Links: 1
Доступ: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Доступ: 2024-06-26 08:25:52.076518894 +0300
Модифицирован: 2024-02-27 13:29:57.552367529 +0300
Изменен: 2024-02-27 13:29:57.553367531 +0300
Создан: 2024-02-27 13:29:57.551367526 +0300
Всё, кроме первой строки вывода этой команды, и есть содержимое метаданных. Они хранятся в индексном дескрипторе файла (inode), номер которого связан с именем файла через элемент в структуре каталога. Именно поэтому запись каталога указывает на индексный дескриптор с метаданными файла — эта связь имени файла и его inode и называется жесткой ссылкой.
Индексные дескрипторы находятся в специальной части файловой системы, которая называется таблицей индексных дескрипторов. Каждый дескриптор с метаданными конкретного файла — запись этой таблицы, условно ее можно назвать строкой. Большая часть файловой системы — это блоки данных.
Третья часть — содержимое
Содержимое хранится в блоках данных файловой системы. Перечень блоков с данными файла запоминается в его индексном дескрипторе.
Таким образом имя связано с индексным дескриптором, а индексный дескриптор — с блоками данных. Все три части файла хранятся отдельно, но логически связаны друг с другом.
Жесткие ссылки
На один и тот же индексный дескриптор могут указывать несколько записей одного или разных каталогов, то есть метаданные и хранимые блоки данных одного и того же файла могут быть представлены разными путевыми именами.
Допустим у нас есть файл file1. Мы можем создать жесткую ссылку для нее командой ln:
$ ln file1 link1
$ ls -il
итого 8
12525 -rw-r--r-- 2 egor egor 42 июн 27 12:46 file1
12525 -rw-r--r-- 2 egor egor 42 июн 27 12:46 link1
Опция -i команды ls позволяет вывести номера индексных дескрипторов отображаемых файлов. В листинге выше мы можем видеть эти номера в первом столбце. Обратите внимание, что они совпадают у файла file1 и созданной командой ln жесткой ссылкой link1. Так что file1 — это такая же жесткая ссылка на метаданные, как и link1, и эти ссылки абсолютно равноправны.
Количество ссылок на файл хранится в метаданных файла, это можно видеть в выводе ls после отображения режимов доступа. В нашем случае там теперь цифра 2.
Работа с содержимым файла возможна через любую из жестких ссылок. Работают любые операции чтения-записи через все путевые имена. Если удалить одну жесткую ссылку, это уменьшит их счетчик, но все остальные продолжат работать. А когда удаляется последняя жесткая ссылка и на метаданные файла более никто не ссылается, в таблице индексных дескрипторов соответствующая запись и блоки данных помечаются как свободные.
Жесткие ссылки можно создавать для объектов в других каталогах. Единственное ограничение: они будут работать только в рамках одной и той же файловой системы.
У механизма жестких ссылок существуют разные полезные варианты применения. Рассмотрим один из них.
Применение жестких ссылок при бэкапе данных
Допустим, у нас есть каталог с данными, который нужно бэкапить каждый день. Если делать это путем обычного копирования, объем резервной копии будет определяться как N × S. В этой формуле N — количество хранимых резервных копий, а S — объем, занимаемый каталогом с данными.
В реальности далеко не все файлы, которые необходимо бэкапить, будут меняться каждый день. Скорее всего, даже наоборот: большинство данных не меняются неделями, потому что пользователи активно работают только со своими текущими проектами, не меняя при этом другие файлы.
Логика резервного сохранения с использованием жестких ссылок получается следующая:
- Первую резервную копию делаем простым копированием исходных данных.
- Для второй резервной копии копируем только файлы, измененные по отношению к содержимому первого бэкапа. А те файлы, которые остались неизменными, в новой резервной копии заменяются на жесткие ссылки на файлы в первой копии.
- При последующих резервных копиях копируются только измененные данные по отношению к предыдущему бэкапу, неизменные заполняются жесткими ссылками.
С таким подходом мы получаем три преимущества по сравнению с классической схемой бэкапа:
- Значительная экономия места на диске. Жесткие ссылки используют только запись в таблице индексных дескрипторов, не занимая блоки данных. Места для хранения резервных копий требуется столько же, как потребовалось бы при использовании однократного полного копирования и дальнейших инкрементальных копий.
- Возможность доступа к данным в резервных копиях и восстановления данных при этом настолько же удобная. Все жесткие ссылки равноправны и позволяют получить доступ к данным файла, поэтому при обращении к любой из регулярных резервных копий мы видим все сохраненные данные.
- Накапливаемые таким образом резервные копии можно также регулярно удалять, начиная с самых старых. Данные останутся доступными через жесткие ссылки в более свежих резервных копиях.
Используем rsync для резервного сохранения
Посмотрим на пример реализации указанного выше подхода. Ниже простейший скрипт с утилитой rsync и опциями, чтобы проставлять жесткие ссылки для неизмененных по отношению к предыдущей копии данных.
#!/bin/sh
$OPT=-avHAX
TGT=$2/$(date +%F--%H-%M-%S)
LINK=--link-dest=../last
rsync $OPT $LINK $1 $TGT
LAST=$2/last
rm -f $LAST
ln -s $TGT $LAST
Скрипт принимает два позиционных параметра: каталог с исходными данными и каталог для хранения резервных копий. В каталоге резервных копий создаются подкаталоги с именами, соответствующими текущей дате (переменная TGT). Чтобы было проще находить предыдущие копии при последующих запусках скрипта, проставим символическую ссылку last в конце на каталог с только что созданной копией. Предыдущая ссылка при этом удаляется.
Используются следующие параметры утилиты rsync:
- -a — стандартная опция архивирования;
- -H — копировать жесткие ссылки как жесткие ссылки;
- -A — копировать атрибуты Posix ACL;
- -X — копировать контекст SELinux;
- -v — вывести список файлов и короткий итог;
- –link-dest=../last — каталог с предшествующей резервной копией для создания жестких ссылок вместо копирования неизменившихся файлов.
Что учесть перед внедрением
Чтобы жесткие ссылки корректно работали в реальных условиях, пример выше нужно доработать под ваши задачи — в таком виде это только прототип. Обратите внимание на уже готовые скрипты резервного сохранения, построенные на базе rsync и использовании жестких ссылок. Один из наиболее известных таких готовых решений — скрипт rsnapshot.
