Недостатки в создании / удалении множества жестких ссылок?

Question

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

Насколько я понимаю, символические ссылки создают небольшой файл, содержащий путь к исходному файлу. Принимая во внимание, что hardlink создает ссылку на данные в том же самом inode. Так что, возможно, если я собираюсь создавать / удалять тысячи этих ссылок, лучше ли создавать и удалять тысячи крошечных файлов (символические ссылки) или тысячи этих ссылок (жестких ссылок)? Кажется, что один облагает налогом жесткий диск (возможно, фрагментацию), а другой может облагать налогом саму файловую систему? Где хранятся ссылки на иноды. Могу ли я испортить файловую систему, сделав так много жестких ссылок? Как насчет скорости?

Спасибо за Ваш опыт!

Это обходной путь, позволяющий использовать ffmpeg для кодирования фильма из произвольного подмножества изображений из каталога. Поскольку ffmpeg требует, чтобы файлы имели правильное имя (например, frame% 04d.jpg), я понял, что могу просто создать жесткие / sym-ссылки на подмножество файлов и просто назвать их соответствующим образом. Это позволяет избежать переименования исходных файлов и необходимости фактически копировать данные. Он отлично работает, но требует многократного создания и удаления тысяч ссылок.

Я тоже считаю, что эта проблема решается так: преобразовать последовательность изображений, используя ffmpeg

Answer 1

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

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

Но разница невелика по сравнению с работой по фактическому чтению данных в файлах.Поэтому я не стал бы беспокоиться об этом, а просто выбрал бы тот, который лучше всего дает вам семантику, которую вы хотите.

Answer 2

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

Однако символические ссылки в / tmp, если / tmp - это tmpfs, еще эффективнее.

Да, символические ссылки слишком малы, чтобы вызвать проблемы фрагментации.

Answer 3

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

Но символьная ссылка требует выделения inode, а файловая система имеет ограничение для inode. Ваши символические ссылки сотни тысяч могут достичь этого предела, и вы можете получить сообщение об ошибке "Недостаточно места для файла" даже при отсутствии гигабайт.

По умолчанию инструмент создания файловой системы выбирает максимальное число inode в соответствии с размером физического раздела. Например, для Linux ext2 / 3/4, mkfs.ext3 использует соотношение bytes-per-inode, которое вы можете найти в вашем /etc/mke2fs.conf.

Для существующей файловой системы, вот команда для получения информации об inode:

# dumpe2fs /dev/sda1 | grep -i inode | less

Inode count:              979200
Free inodes:              742304
Inodes per group:         16320
Inode blocks per group:   510
First inode:              11
Inode size:               128
Journal inode:            8
First orphan inode:       441066
Journal backup:           inode blocks

В заключение следует предпочесть жесткие ссылки в основном для потребления ресурсов на диске и в памяти (структуры VFS в кешах).

Еще один совет: не создавайте слишком много файлов в одном и том же каталоге, 2 000 файлов - разумный предел, чтобы избежать проблем с производительностью.