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

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

Нижний левый график показывает планки погрешностей, указывающие минимальное и максимальное измеренное время для cat для 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 , чтобы уменьшить общее количество точек и, следовательно, генерируемых данных.
  • Использование памяти бэкэндом zstd кажется огромным только потому, что он использует mmapдля открытия. Память, используемая mmap, даже не считается используемой памятью при отображении использования памяти с помощью freeили htop.
• Для пустых файлов монтирование с помощью ratarmount и archivemount, по-видимому, не ограничено ни декомпрессией, ни пропускной способностью ввода-вывода, а скорее алгоритмом создания внутреннего файлового индекса. Этот алгоритм линейно масштабируется для ratarmount, но кажется, что он хуже, чем даже квадратичный, для архивов >100GB при использовании archivemount.

Минусы

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

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