LINUX.ORG.RU

ratarmount 1.0.0

 , , , ,


1

2

Программа ratarmount (random access tar mount) предназначена для монтирования архивных файлов в файловую систему и позволяет монтировать через FUSE не только файлы tar (сжатые bz2, gz, xz или zstd) TAR, но и zip и rar. Новый релиз 1.0.0 доступен к установке из pip и AppImage.

Есть несколько особенностей, отличающих ratarmount от существующего archivemount. В первую очередь доступ к смонтированным файлам на самом деле быстрый, независимо от размера архива. Например, для архивов размером 100 ГБ мы говорим о миллисекундах задержки с ratarmount против часов задержки с archivemount. Кроме того, ratarmount имеет распараллеленный bz2- и xz-декодер, а также предлагает расширенные функции, такие как создание индексного файла для быстрого последующего доступа, объединение монтирования, связывание монтирования и даже произвольное глубокое рекурсивное монтирование.

Возможности:

- Быстрый произвольный доступ (создание индекса, содержащих точки поиска);
- Рекурсивное монтирование (TAR в TAR в TAR в ...);
- Использование параллелизации в алгоритмов (TAR,GZ,BZ,...)
- Объединенное монтирование (несколько TAR-файлов в одну точку монтирования)
- Удаленные протоколы доступа (FTP, HTTP, HTTPS, SFTP, SSH, Git, Github, S3, Samba v2 и v3, Dropbox, ...)

>>> Подробности

★★★★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 7)

Интересно, как это сделано? Он сначала сканирует весь архив и записывает оффсеты блоков? Возможно ли таким образом подмонтировать тарбол по http не скачивая его полностью?

mittorn ★★★★★
()

Удаленные протоколы доступа (FTP, HTTP, HTTPS, SFTP, SSH, Git, Github, S3, Samba v2 и v3, Dropbox, ...)

Если эта штука архивы монтирует, то ей нужен доступ по сети?

Rodegast ★★★★★
()
Ответ на: комментарий от mittorn

Возможно ли таким образом подмонтировать тарбол по http не скачивая его полностью?

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

sena ★★
()
Ответ на: комментарий от sena

Потому, что ленточные накопители еще не умерли :) А он по жизни Tape ARchiver

gns ★★★★★
()
Ответ на: комментарий от firkax

Потому что рандом доступ к архиву обычно не нужен.

Обычно да, но если нужен… Накладные расходы на хранение таблицы смещений минимальны.

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

sena ★★
()
Ответ на: комментарий от sena

Ну zip сам по себе в этом плане не удобен. У его индекс в конце файла и его не удобнопо этому использрвать. Конечно zip имеет потоковые упаковщики и распаковщики, но с кучей огианичений. Для zip я реализовывал http сервер который может как скачать зип с упаковкой налету, так и залить с распаковкой налету. Но т.к в zip чексумма пишется до файла, а не после и zip не позволяет писать размер файла и не записать чексумму, размер файла не пишется и при распаковке длина определяется по окончанию сжатого потока.
А для задач со случайным доступом я использовал iso и squashfs. Эти форматы уже расчитанны под оптимальный рандомный доступ на устройствах с долгим временем запрсоа (cd) и из-за этого остаётся оптимальным и для сети. Не помню как squashfs, но iso может создаваться потоково, сразу записываясь на диск - для этого он считает размеры файлов до создания образа. Со сжатием конечно сложнее т.к ты не знаешь сжатый размер заранее, вероятно squashfs нельзя создать в потоковом режиме.
В любом случае придётся выбирать два из трёх:
Случайный доступ
Потоковое сжатие архива
Сжатие
Есть конечно компромис в виде индекса в конце как у зипа. То есть zip нужно всего лишь сделать возможность указания размера файлов в непотоковом режиме и тогда его можно будет и создавтаь и распаковывать потоково, а не что-то одно. А с zlib-1 сжатием в принципе zip и так может потоковое сжатие + random access, но для random access нужно знать размер файла чтобы заранее считать его конец

mittorn ★★★★★
()
Ответ на: комментарий от sena

Вот там, где нужен (по мнению тех кто пакует), там и используют другие форматы. А там, где ненужен, он ненужен полностью. К тому же рандом доступ несовместим со сквозным gzip.

firkax ★★★★★
()
Ответ на: комментарий от sena

один из выходов как в «расширяемом» pdf - оглавление в конце - но если только обновления - получается обратно хронологический список размазанный по всей ленте от конца к началу

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

qulinxao3 ★★
()
Ответ на: комментарий от mittorn

zip вообще пиндисен не хранит в базовом варианте кодировку имён дерева объектов просто байтовые поля - всё как завещал автор

«все %»№;%:? кроме я"

qulinxao3 ★★
()
Ответ на: комментарий от qulinxao3

ну либо индекс один всегда в конце и при дописывании:

зачитали(из последний хаха бит) позицию(либо размер насколько ленту к началу отмотать от текущего конца ) где индекс начинается и сам индекс Индекс

с места Индекса записали обнову

выгрузили Индекс + запись позиции обновы + инфа где_же_индекс

qulinxao3 ★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.