Лучшая read-only filesystem?

Посмотри erofs

Разве не UDF всегда используют в таких сценариях?

ныряй в базы данных

всяко там есть RO data storage structures

https://en.wikipedia.org/wiki/Persistent_data_structure

https://lmgtfy.app/?q=read only data store architecture

али тебе с нея грузится?

https://en.wikipedia.org/wiki/Persistence_(computer_science)

ISO 9660?

Не тупи. man tar

али тебе с нея грузится?

Не, просто архивчик. Как ты с зашифрованного загрузишься?

Не тупи. man tar

Ага, а потом чтобы один единственный файл считать, надо все 50 гиг шерстить-распаковывать.

ISO 9660?

А что, в ней можно любой обычный диск форматнуть? (Ну т.е. в данном случае /dev/mapper/my-ro-image.)

Так там же адресация на место, где лежит, есть.

1кб декриптора хватит всем(с)

Ну нет ибо как pdf можно сразу после make tar 50gb again одним линейным сканом собрать таблицу смещений и оставить в/под хвост(е/) тарчика [Аля xref pdf]

А уж если замодить тарщик то и без отдельного прохода и хвост типо и часть тарфайла и мета онём

Сомневаюсь, но и в squashfs вроде тоже нельзя.

Ридонли они на то и ридонли, что форматируются обычно тулзой вместе с добавлением всех файлов, а потом монтируются.

SquashFS это же уже контейнер т.е. другой алгоритм, типа такого: https://gist.github.com/ansemjo/6f1cf9d9b8f7ce8f70813f52c63b74a6

А он не офигеет потом какой-нибудь один файл доставать из середины архива на 50 гигов?

Если tar без сжатия поверх, то просто переходить по смещению на нужный файл будет.

Для разнообразия предлагаю рассмотреть вариант использования архивного формата и записи его на диск как есть. tar, zip, 7-zip, rar, что больше нравится. К примеру у rar есть избыточность, есть возможность быстро распаковывать произвольный файл.

Про dar забыл ещё.

Встроенной в архиваторы шифрации не доверяю, а с внешней поверх – опять же придётся ради одного файла весь архив считывать.

таков юниксвей

Встроенной в архиваторы шифрации не доверяю

Надо доверять. Она нормальная.

с внешней поверх – опять же придётся ради одного файла весь архив считывать.

Не придётся. LUKS расшифровывает тот сектор, который запрашивается. Разницы никакой не будет. Если речь не о tar, там, конечно, придётся, но это особенность формата, шифрование тут не при чём.

Да ладно, а зачем тогда tarindexer и Ratarmount существуют?

Вот у меня tar-архив 5 Гб не сжатый, там 328 тыс. файлов. Если смотреть вывод strace tar -t -f то там около 127 тыс. операций read() на этот файл и 24 тыс. операций lseek().

Если strace'ом смотреть кол-во read()/lseek() для извлечения одного файла (tar -x имя_файла -f ), то числа не меняются. Читаются заголовки всех файлов из архива, так как могут быть более поздние версии.

Вот если у ТС в архиве будут файлы по 1 Гб, то всё хорошо, tar мнгновенно будет пробегать по заголовкам всех файлов, пропуская (lseek) их тело...

Я думал ты про tar без luks. А если внутри luks, то я так понимаю без FS – имеется в виду tar c... > /dev/mapper/my-image. Неудобно: с FS видно, сколько свободного места осталось, можно подгонять под максимальное заполнение, добавляя-удаляя файлы.

Я думал ты про tar без luks. А если внутри luks, то я так понимаю без FS – имеется в виду tar c… > /dev/mapper/my-image.

Да разницы нет, с luks или без. Без luks будет tar > /dev/sda. С luks будет tar > /dev/mapper/img. А лучше сначала в файл, и потом файл уже скопировать на устройство.

Неудобно: с FS видно, сколько свободного места осталось, можно подгонять под максимальное заполнение, добавляя-удаляя файлы.

Я не вполне понимаю твой workflow. Я бы делал так: сначала создал бы папку. В неё добавил бы нужные файлы. Через du можно оценить её размер до сжатия. Потом бы сжал папку в архивный файл с помощью 7z или rar. И далее этот файл записал бы на диск.

Если хочется именно с LUKS, то после архивации надо создать новый файл размера чуть больше, чем архивный файл. Отформатировать его как контейнер и подключить через cryptsetup luksFormat / cryptsetup open. Далее через dd скопировать архивный файл в /dev/mapper/xxx. Закрыть контейнер и всё. Далее файл с контейнером можно записывать на диск.

Подгонять размер тут, конечно, будет неудобно, т.к. со сжатием это всегда не очень детерминированно. Если отказаться от сжатия (в принципе любой архиватор это позволяет), то проблем не будет, размер архива будет примерно равен размеру каталога. Если не отказываться, то будет чуть больше возни.

Основной плюс файловой системы на мой взгляд это возможность монтировать её и иметь непосредственный доступ к файлам внутри. С архивами это не так просто.

В вики пишут

UDF возможно использовать как кросс-платформенную альтернативу файловой системе FAT. 

Правда что ли?

Как минимум можно попробовать. Но я не пробовал.

м-м-м, а если просто использовать любую шифрованную фс ??
монтировать ее в ro. писать на нее никто все не будет.

Я предпочитаю unix way aka SRP: шифрование отдельно, ФС отдельно. Преимущества в плане гибкости очевидны уже хотя бы по этому треду: вон уже напихали вариантов с шифрованием, но без ФС. И вообще, с cryptsetup я уже давно знаком, а эти ваши btrfs первый раз вижу. (c) папа Дяди Фёдора

А зачем тебе именно RO файловая система? Тебе BD-R и так RO обеспечит.

Не изгаляйся, и делай обычный ext4, или что ты там любишь. Если груман, можешь журнал отключить.

BD-R - ISO9660 - file-image - cryptsetup - ext4 - files

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

Встроенной в архиваторы шифрации не доверяю

Можете сурсы посмотреть. Но конечно зависит чего и от кого защищаете.

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

це ж линукс !! свобода и лего-конструктор !!

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