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 ★★
()
Ответ на: комментарий от 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 ★★
()
Ответ на: комментарий от greenman

Вот, dar - отличный кандидат. Только он должен стоять по-умолчанию в базовой системе, вместе с bash, grep и tar.

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

И кстати совместимость ты таки поломаешь этим. Чтобы дописывать в конец таблицу, её надо где-то хранить всё время работы, в итоге, если там очень много файлов, tar может сожрать всю память и упасть там, где обычный tar работал бы бесконечно без проблем (реально бесконечно, ему не надо даже знать на какой позиции выводного потока он сейчас находится, так что он может сгенерить поток длиной не укладывающейся ни в какие разрядности хоста).

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

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

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

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

pfg ★★★★★
()

помимо отсуствующего индекса тарпердобола есть еще «тяжелый» вопрос.
как дается доступ к произвольному месту внутри непрерывного сжатого потока (bz2 gz xz или иное не важно).
это непрерывный архив, в середину него просто так не влезешь, в отличии, к примеру, от зип - там пофайловое сжатие (ну и индекс).

непрерывно-блочные методы сжатия есть только в раре и 7зип.

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

ну эта проблема решаемая, если сделать таблицу опциональной или ограниченной по размеру

sena ★★
()
Последнее исправление: sena (всего исправлений: 1)

Отличная штука, пользуюсь с версии 0.5, после archivemount был прям вау эффект)

screamager
()
Ответ на: комментарий от pfg

Я когда-то пользовал, было дело. Чем сейчас на ленточные библиотеки пишут понятия не имею.

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

Его разработка должна вестись сообществом.

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

рар сохраняет, но не всё :)
squashfs вообще ориентировался на линукс. и потому умеет всё линухово
вотъ

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