На данный момент я использую ArchiveMountдля монтирования архива в 123000 кб, который содержит более 3 миллионов файлов внутри. До сих пор он монтировался более 5 часов и до сих пор не закончен.

Есть ли лучший способ смонтировать .tar.gzфайл? Я пытаюсь смонтировать в папку, и без сжатия требуется несколько концертов. Мне даже не нужен режим записи, достаточно только чтения.

Вы также можете создать сжатый образ squashfs

mksquashfs /etc squashfs.img -comp xz
mkdir img
mount -o squashfs,ro squashfs.img img

Для этого вам нужно распаковать архив tar.gz.

Преимущество также в том, что изображение имеет лучшую отказоустойчивость, чем gz.

Проблема здесь в том, что формат TAR (Tape ARchive) предназначен для последовательного доступа, а не произвольного доступа. И gzip является хорошим дополнением к tar, поскольку это формат сжатия на основе потоков, также не для произвольного доступа.

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

Если вы хотите, чтобы это происходило быстрее, сделайте a tar tzf file.tar.gz > filelist, откройте список файлов в vim , gedit или в любом другом месте , удалите строки файлов, которые вам не нужны, сохраните, а затем извлеките их tar xzf file.tar.gz -T filelist -C extracted/.

Чтобы получить произвольный доступ к сжатому файлу, вам следует использовать zip с расширениями posix, rar или, как предположил dru8274, squashfs или даже ZFS с включенным сжатием, или btrfs, если btrfs включил сжатие во время чтения.

Я написал более быстрый альтернативный ratarmount , который «работает для меня», потому что эта проблема продолжала беспокоить меня.

Вы можете использовать это так:

pip3 install --user ratarmount
ratarmount my-huge-tar.tar mount-folder
ls -la mount-folder # will show the contents of the tar top-level

Когда вы закончите, вы можете размонтировать его, как любое крепление FUSE:

fusermount -u mount-folder

Почему это быстрее, чем архивирование?

Это зависит от того, что вы измеряете.

Вот эталон объема памяти, необходимого времени для первого монтирования, а также времени доступа для простой cat <file-in-tar>команды и простой findкоманды.

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

На нижнем левом графике показаны столбцы ошибок, указывающие минимальное и максимальное измеренное время cat <file>для 10 случайно выбранных файлов.

Время поиска файла

Убийственное сравнение - это время, которое нужно, cat <file>чтобы закончить. По какой-то причине это масштабируется линейно с размером файла TAR (приблизительно байт на файл x количество файлов) для архивного монтирования при постоянном времени в ratarmount. Это делает его похожим на то, что archivemount вообще не поддерживает поиск.

Для сжатых файлов TAR это особенно заметно. cat <file>занимает в два раза больше времени, чем монтирование всего файла .tar.bz2! Например, для TAR с 10k пустых (!) Файлов требуется 2,9 с для монтирования с помощью archivemount, но в зависимости от файла, к которому осуществляется доступ, доступ с помощью catзанимает от 3 мс до 5 с. Время, которое требуется, зависит от положения файла внутри TAR. Файлы в конце TAR требуют больше времени для поиска; указывает, что эмулируется «поиск», и все содержимое в TAR до чтения файла.

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

Ratarmount, похоже, всегда получает одинаковое количество времени, чтобы получить файл, потому что он поддерживает истинный поиск. Для сжатых TAR bzip2 он даже ищет блок bzip2, адреса которого также хранятся в индексном файле. Теоретически, единственная часть, которая должна масштабироваться с количеством файлов, - это поиск в индексе, который должен масштабироваться с O (log (n)), потому что он сортируется по пути и имени файла.

След памяти

В общем, если у вас есть более 20 тыс. Файлов внутри TAR, то объем памяти ratarmount будет меньше, поскольку индекс записывается на диск по мере его создания и, следовательно, в моей системе имеет постоянный объем памяти примерно 30 МБ.

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

Напротив, archivemount сохраняет весь индекс, который составляет, например, 4 ГБ для файлов 2M, полностью в памяти до тех пор, пока смонтирован TAR.

Время монтажа

Моя любимая особенность - возможность ratarmount смонтировать TAR без заметной задержки при любой последующей попытке. Это связано с тем, что индекс, который отображает имена файлов в метаданные и положение в TAR, записывается в файл индекса, созданный рядом с файлом TAR.

Требуемое время для монтирования ведет себя странно в архиве. Начиная примерно с 20 тыс. Файлов, он начинает масштабироваться квадратично, а не линейно по отношению к количеству файлов. Это означает, что, начиная примерно с 4М файлов, ratarmount начинает работать намного быстрее, чем архивирование, даже если для небольших файлов TAR это происходит в 10 раз медленнее! Опять же, для небольших файлов не имеет большого значения, требуется ли 1 или 0,1 секунды для монтирования tar (в первый раз).

Время монтирования сжатых файлов bz2 является наиболее сопоставимым во все времена. Это очень вероятно, потому что это связано со скоростью декодера bz2. Ratarmount здесь примерно в 2 раза медленнее. Я надеюсь, что в ближайшем будущем ratarmount станет явным победителем благодаря распараллеливанию декодера bz2, что даже для моей 8-летней системы может привести к ускорению в 4 раза.

Время получать метаданные

При простом перечислении всех файлов findвнутри TAR (команда find также вызывает статистику для каждого файла !?), ratarmount в 10 раз медленнее, чем archivemount для всех проверенных случаев. Я надеюсь улучшить это в будущем. Но в настоящее время это выглядит как проблема дизайна из-за использования Python и SQLite вместо чистой программы на Си.

Это не охватывает все варианты использования, поскольку ограничивает использование текстовым редактором. Но если вам нужен только доступ для чтения, это может оказаться полезным в некоторых ситуациях. vim, при запуске в tarball покажет вам иерархию содержимого архива (аналогично тому, как будет отображаться иерархия файлов при запуске в каталоге). Выбрав один из файлов в списке, он откроет выбранный файл в буфере только для чтения.

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

Примечание : это не будет работать на всех форматах архива.

Мой подход. Если у вас достаточно свободного дискового пространства на внешнем USB-накопителе или внешнем / дополнительном жестком диске с достаточным пространством, подумайте об извлечении файла .tar.gz. Думая, что вы, вероятно, не хотите 3 миллиона файлов на вашем системном диске, поскольку это может замедлить процесс. Я бы порекомендовал, чтобы внешний диск в этом случае имел файловую систему, которая легко обрабатывает огромное количество файлов: например, ReiserFS, ext4 (с опцией dir_index), XFS, возможно, BtrFS. Для извлечения может потребоваться 1-2 часа, но вы можете просто пойти пообедать или оставить его на ночь; когда вы вернетесь, доступ к извлеченным файлам должен быть быстрым.