Более быстрая альтернатива ArchiveMount?

Попробуйте эту команду:

sudo -i bash
15
10.05.2015, 11:22
5 ответов

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

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

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

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

5
27.01.2020, 19:50
  • 1
    Для получения произвольного доступа к сжатому файлу Вы могли также использовать pixz. –  kubanczyk 29.06.2014, 23:42

Вы могли также создать сжатое изображение squashfs

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

Чтобы сделать это, необходимо будет извлечь tar.gz archvie.

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

7
27.01.2020, 19:50

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

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

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

0
27.01.2020, 19:50

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

0
27.01.2020, 19:50

Я написал более быструю альтернативу 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.

Benchmarks

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

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

Плюсы

  • Не показано в тестах, но ratarmount может монтировать файлы с уже существующими вспомогательными файлами индекса менее чем за секунду, что делает его значительно более эффективным по сравнению с archivemount для каждого последующего монтирования .
  • Ratarmount поставляется с индикатором выполнения , так что, в отличие от archivemount, пользователям не нужно ждать часами, не получая никакой обратной связи.
  • Получение содержимого файла смонтированного архива, как правило, значительно быстрее , чем archivemount, и, в отличие от archivemount, не увеличивается с размером архива или количеством файлов, что приводит к наибольшему наблюдаемому ускорению. около 5 порядков!
  • Монтирование bzip2 архивов на самом деле стало быстрее по сравнению с archivemount с ratarmount -P 0на большинстве современных процессоров, потому что archivemount использует только одно ядро ​​для декодирования bzip2. indexed_bzip2поддерживает блочное параллельное декодирование начиная с версии 1.2.0.
  • Потребление памяти ratarmount в основном меньше чем archivemount и в большинстве случаев не увеличивается с размером архива.
    • Серверная часть gzip растет линейно с размером архива, потому что данные для поиска в тысячи раз больше, чем простые два 64-битных -смещения, необходимые для bzip2. Если это становится проблемой, вы можете увеличить расстояние между точками поиска, используя --gzip-seek-point-spacing <spacing in MiB>, чтобы уменьшить общее количество точек и, следовательно, генерируемых данных.
    • Использование памяти бэкэндом zstd кажется огромным только потому, что он использует mmapдля открытия. Память, используемая mmap, даже не считается используемой памятью при отображении использования памяти с помощью freeили htop.
  • Для пустых файлов монтирование с помощью ratarmount и archivemount, по-видимому, не ограничено ни декомпрессией, ни пропускной способностью ввода-вывода, а скорее алгоритмом создания внутреннего файлового индекса. Этот алгоритм линейно масштабируется для ratarmount, но кажется, что он хуже, чем даже квадратичный, для архивов >100GB при использовании archivemount.

Минусы

  • К сожалению, gzip сжатые файлы TAR примерно на один порядок медленнее с ratarmount, чем с archivemount при первом монтировании. Но это замедление будет амортизировано после второго последующего монтирования благодаря индексному файлу.
  • Получение большого количества метаданных для содержимого архива, как показано вызовом findв точке монтирования, как правило, более чем на порядок медленнее по сравнению с archivemount, вероятно, из-за Python и Слой SQLite в отличие от реализации на чистом C или потому, что я использую FUSE в режиме одного потока -.

Дополнительные сведения о -тестах глубины см. на странице Github .

15
27.01.2020, 19:50

Теги

Похожие вопросы