Когда было бы полезно создать жесткую ссылку?

Существуют два основных ограничения для жестких ссылок:

1. Жесткие ссылки обычно требуют, чтобы ссылка и файл находились в одной файловой системе.
2. Только суперпользователь может создать жесткую ссылку на каталог.

Таким образом, символические ссылки были введены, чтобы обойти ограничения жестких ссылок. Итак, вопрос в том, нужны ли еще жесткие ссылки? Может ли быть ситуация, когда они более полезны?

Жесткие ссылки помогают нам организовать нашу файловую систему гораздо более гибко. По сути, жесткие ссылки позволяют нам взять один файл и иметь его в нескольких местах в файловой системе одновременно. Подумайте о сценарии, когда вы фотограф и у вас много фотографий (это пример из моей жизни!). Вы можете организовать их по людям, которые появляются в них, потому что иногда люди просят вас сфотографировать их. Но вы также можете организовать их по месту и дате. Нет никакого реального способа вложить эти три вещи, они - полностью отдельные оси организации. Таким образом, вы можете создать три разные иерархии для этих трех разных вещей, и каждая фотография будет представлена ​​во всех трех безхранить каждую фотографию три раза. Это магия жестких ссылок. Отключите символические ссылки, нам не нужно беспокоиться о том, где находится «настоящий файл», потому что все они - настоящий файл. Мы можем удалять и перемещать по желанию, поскольку файл будет сохраняться до тех пор, пока на него больше не будет никаких ссылок, и удаляется при удалении последней жесткой ссылки. Это просто и не требует от вас очень много отслеживать.

Содержимое файла не будет очищено до тех пор, пока все жесткие ссылки (да, все имена файлов являются жесткими ссылками, даже первые) не будут удалены и файл не будет закрыт. Таким образом, это может быть полезно, когда файл требуется в нескольких местах, но может быть удален из любого из них в любое время, например, между ~/Downloads/coolsong.mp3и ~/Music/Cool Song.mp3.

Одно не очень важное преимущество жесткой ссылки перед символической ссылкой состоит в том, что когда она достигает inode для жесткой ссылки, ядро ​​не имеет дальнейшей обработки для доступа к файлу. Когда он встречает символическую ссылку, ядро ​​должно прочитать значение ссылки и продолжить обход структуры каталогов, прежде чем попасть в индекс для файла. Это занимает больше времени, хотя разница не всегда легко измеряется. Это становится действительно забавным, когда один из элементов значения символической ссылки сам является символической ссылкой.

Есть несколько причин для жестких ссылок

1. сохранять ссылки на файл до тех пор, пока не исчезнет последняя ссылка (как указал Игнасио)
2. когда вы жестко связываете файлы, они занимают только место одного файла в файловой системе (обе ссылки на файл имеют одни и те же i-узлы). Поэтому жесткие ссылки должны быть в одной файловой системе.

Поэтому одной из причин использования жестких ссылок является возможность сэкономить много места ...

Вы можете добавить к любой из ссылок, и данные отправляются в общий файл. Вы также можете добавить один файловый дескриптор, читая другой (например, с помощью tail -f)

Многие из приведенных здесь примеров действительны, но одинаково хорошо работают с программными ссылками (например, проблема «нужен один файл в нескольких местах»).

Хорошим примером того, где жесткие ссылки действительно полезны, является программа резервного копирования Dirvish :

Dirvish - это быстрая дисковая вращающаяся сетевая система резервного копирования.

С Dirvish вы можете поддерживать набор полных образов ваших файловых систем с автоматическим созданием и истечением срока действия. Хранилище резервных копий как машина времени для ваших данных.

Dirvish создает резервные копии на уровне файловой системы (то есть копирует файлы, но не создает образы), копируя файлы в отдельную (резервную) файловую систему (например, жесткий диск USB). Каждый раз, когда вы делаете резервную копию, dirvish создает отдельную полную копию дерева каталогов для сохранения.

Хитрость заключается в том, что если dirvish обнаруживает, что уже существует более старая резервная копия дерева, которое вы сохраняете, он автоматически повторно использует файлы, которые не были изменены, создавая жесткую ссылку в новом дереве на файл в старом дереве.

Таким образом, каждая резервная копия является полной, автономной копией дерева каталогов, но в то же время только измененные файлы фактически занимают место в файловой системе. Другими словами, вы получаете преимущества инкрементного резервного копирования (экономия места) и полного резервного копирования (простое извлечение) одновременно.

Это возможно только потому, что жесткие ссылки полностью прозрачны для инструментов пользовательского пространства.

Это, вероятно, также будет работать с символическими ссылками (хотя у вас могут возникнуть проблемы при резервном копировании данных, в которых используются символические ссылки), но одно преимущество, которое возможно только с жесткими ссылками:

Если вы хотите выбросить старые резервные копии, вы можете просто удалить соответствующее дерево каталогов резервных копий. Файлы, связанные только с этим деревом, автоматически удаляются файловой системой (поскольку удаляется их последняя жесткая ссылка), но файлы, которые также появляются в других копиях, остаются на диске.

Скажем, один полезный случай - когда у вас есть программа (или сценарий), которая должна загрузить большой временный архив, и после распаковки ваша программа немедленно его удалит.

Если по какой-то причине вы хотите сохранить этот tar-архив для использования в будущем, лучше всего, ln /tmp/tarball.tgz ~пока он еще загружается. Тогда вам не нужно ничего делать.

Когда загрузка завершится, и даже после того, как ваша программа удалила «оригинальную», точная копия все равно должна находиться в вашем домашнем каталоге.

Я использую «Hard Links» для резервного копирования некоторых моих «HowTos» и фрагментов

У меня есть каталог с именем «Shared Docs» в моем пользователе / ​​root. В этом каталоге у меня есть «жесткие ссылки» на мои советы, хитрости, фрагменты, инструкции, которые находятся в соответствующих каталогах; php, mysql, css, regex, формулы, linux и т. д. Хранить их в «одном месте» намного проще в использовании, обновлять их, чем прыгать по моим документам / каталогам в поисках этих документов, которые я часто использую.

Давным-давно я использовал символические ссылки. Я бы искренне сделал резервную копию этой общей папки «Shared Docs» на моем сервере. Проблема заключается в том, что символические ссылки или «мягкие ссылки», если скопированы (cp -auv) или скопированы и скопированы, ТОЛЬКО выполняют резервное копирование или копируют «ссылку», а НЕ содержимое документа. Итак, мне придется пройтись по каталогам и скопировать каждый из 2 дюжин файлов с их фактического местоположения.

С помощью HARD LINKS я могу копировать, tar, rsync каталог «Shared Docs» и на самом деле делать резервные копии этих широко рассредоточенных документов с уверенностью, содержимое фактически резервируется. Это действительно отстойно для меня, когда я понял, что я резервировал 0 кусков «файлов ссылок», а не информации.

Недостатком использования «жестких ссылок» является то, что выполнение ls для каталога не дает вам указания на то, что файл «связан» с другим файлом или где этот файл может сосуществовать. Есть способы найти их, но я говорю, что это неочевидно с помощью простых ls -l -> указывает на ... Итак, я обычно добавляю примечание в начало документа, указывающее, какой каталог / файлы 'этот файл «поделился» с

Landis.