Вопрос или проблема
В руководстве по команде tar указана опция для следования жестким ссылкам.
-h, --dereference
следовать символическим ссылкам; архивировать и сохранять файлы, на которые они указывают
--hard-dereference
следовать жестким ссылкам; архивировать и сохранять файлы, на которые они ссылаются
Как tar узнает, что файл является жесткой ссылкой? Как он за ней следует?
Что если я не выберу эту опцию? Как он не использует жесткое разрешение ссылок?
По умолчанию, если вы указываете tar архивировать файл с жесткими ссылками, и более чем одна такая ссылка включена среди файлов для архивации, он архивирует файл только один раз и записывает второе (и любые дополнительные имена) как жесткие ссылки. Это означает, что при извлечении архива жесткие ссылки будут восстановлены.
Если вы используете опцию --hard-dereference, тогда tar не сохраняет жесткие ссылки. Вместо этого он рассматривает их как независимые файлы, которые просто имеют одинаковое содержимое и метаданные. При извлечении архива файлы будут независимыми.
Примечание: Он распознает жесткие ссылки, сначала проверяя количество ссылок файла. Он записывает номер устройства и инода каждого файла с более чем одной ссылкой и использует это для обнаружения, когда тот же файл архивируется снова. (Когда вы используете --hard-dereference, он этого не делает.)
Вы можете отличить файл с жесткими ссылками на него от файла без жестких ссылок, по “количеству ссылок”. Я вижу два способа получить это из командной строки:
% stat original
Файл: ‘original’
Размер: 0 Блоки: 0 IO Блок: 4096 регулярный пустой файл
Устройство: 804h/2052d Inode: 932815 Ссылки: 2
Доступ: (0644/-rw-r--r--) Uid: ( 500/ bediger) Gid: ( 1000/ bediger)
Доступ: 2012-07-13 22:13:52.317101530 -0600
Изменение: 2012-07-13 22:13:52.317101530 -0600
Изменение атрибутов: 2012-07-13 22:14:08.050894536 -0600
Рождение: -
Или
1010 % ls -li
итого 0
932815 -rw-r--r-- 2 bediger bediger 0 июл 13 22:13 original
932815 -rw-r--r-- 2 bediger bediger 0 июл 13 22:13 secondary
Эта одиночная ‘2’ перед “bediger” — это количество ссылок. Обратите внимание, что оба имени файлов имеют один и тот же номер инода — 932815.
Я уверен, что обе эти команды получают количество ссылок из поля st_nlink структуры stat, которая заполняется системным вызовом stat().
Насколько я могу судить, запуск tar с --hard-dereference означает, что вместо получения одного файла с двумя разными именами (как в примере выше), вы получаете два файла, каждый с одним именем. tar вероятно проверяет количество ссылок у каждого файла и по умолчанию при извлечении, создает жесткую ссылку на второе имя файла, которое у него есть для данных с жесткими ссылками. Когда вызывается с --hard-dereference при создании архива, он, похоже, создает совершенно новый файл для второго имени файла, когда выполняется извлечение tar.
Ответ или решение
Вопрос о том, как команда tar обрабатывает жёсткие ссылки при архивации файлов, весьма интересен и важен для IT-специалистов, работающих с файловыми системами. Рассмотрим это подробно.
Теория
В UNIX-подобных операционных системах жёсткие ссылки (hard links) позволяют нескольким именам файлов указывать на один и тот же участок данных на диске. Эффективно это означает, что несколько различных путей в файловой системе могут указывать на одно и то же физическое местоположение данных. Система использует понятия inode и device number для идентификации конкретного файла в системе. Жёсткие ссылки имеют одно и то же inode, что отличает их от символических ссылок (symlinks).
Команда tar, используемая для архивации данных, предоставляет возможность как учёта, так и игнорирования жёстких ссылок с помощью опций --hard-dereference и -h (или --dereference). Когда tar создает архив без указания опции --hard-dereference, он сохраняет информацию о жёстких ссылках, что позволяет восстановить их во время извлечения архива. В этом случае файл с несколькими жёсткими ссылками будет помещён в архив только один раз, а дополнительная информация будет использоваться для восстановления нескольких ссылок на него при извлечении.
Пример
Предположим, у нас есть два файла original и secondary, являющихся жёсткими ссылками друг на друга. Это можно определить с помощью команд stat или ls -li, которые показывают одинаковый inode и увеличенное значение link count (числа ссылок).
Пример вывода команды ls -li для иллюстрации:
932815 -rw-r--r-- 2 bediger bediger 0 Jul 13 22:13 original
932815 -rw-r--r-- 2 bediger bediger 0 Jul 13 22:13 secondaryЗдесь 932815 – это номер inode, а 2 – это число ссылок. Это говорит о том, что оба файла указывают на один и тот же inode.
Применение
Во время выполнения команды tar с опцией --hard-dereference, жёсткие ссылки рассматриваются как независимые файлы. Это значит, что каждый из них будет обработан и сохранён отдельно, как будто это разные файлы. То есть, при извлечении архива в таком формате, original и secondary будут существовать как самостоятельные файлы без каких-либо взаимосвязей.
Если же команда tar выполняется без этой опции, то во время создания архива tar проверяет значения link count и сохраняет один файл на всех жёсткие ссылки. При извлечении такого архива из tarball жёсткие ссылки будут воссозданы. Таким образом, при распаковке архива классическим способом, восстановленные файлы будут указывать на один общий inode, сохраняя оригинальные связи.
Для профессионального использования важно понимать разницу в поведении команды tar с и без этой опции. Архивирование с учётом жёстких ссылок экономит место и сохраняет связывание данных, что может быть критически важным при разработке, администрировании серверов, или при работе с резервными копиями. С другой стороны, создание независимых копий файлов (используя --hard-dereference) может быть полезным, когда необходимо избежать взаимной зависимости данных.
Резюмируя, ключ к пониманию работы tar и жёстких ссылок – это структурный подход системы к управлению файлами через inodes и device numbers. При этом грамотное использование опций команды tar позволяет контролировать способ архивирования и извлечения данных, обеспечивая гибкость в работе с файловыми системами.
Таким образом, имея эти знания, специалисты могут более эффективно управлять данными в UNIX-подобных системах, создавать оптимальные процессы резервного копирования и восстановления, а также минимизировать риск потери данных.