SquashFS вместо tar.gz для архива

Что мешает использовать SquashFS вообще везде, где раньше был TAR?

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

Для обычного бекапирования данных - ни вижу причин, не использовать SquashFS. Сам так делаю. В tar.gz тоже храню, но это где система бекапа так настроена или данные которые если нужны, то 100% распаковываются.

я подозреваю что этот формат не настолько окаменел, как TAR + GZIP, и лет через 20 для монтирования образа может потребоваться некоторая некромантия.

Фраза немного не понятна. Подразумевается, что SquashFS это что-то малоизвестное и слабо используемое?

• Эта Read-only FS по умолчанию во всех iso - самый большой файл внутри и часто имеет разное расширение и название.
• Есть некоторое количество дистрибутивов, построенных на преимуществах Read-only FS (неубиваемость системы) и имеющих механизм сохранение сессии при перезагрузке/выключении, а также умеющих создавать модули новых приложений и подключать их сразу, на ‘горячую’ или после перезагрузки. Это Puppy Linux, Slax, Porteus, MagOS…
• Conty от Kron4ek, Новая альтернатива flatpak и appimage - контейнер в виде одного файла.

Кстати, в Conty используется две разных FS, это SquashFS и DwarFS. Причем утверждается, что «Помимо лучшего сжатия, DwarFS также имеет лучшее кэширование и лучшую поддержку многопоточности, и, по моему опыту, она читает сжатые файлы заметно быстрее, чем SquashFS».

Здесь имеется в виду, что за много лет формат может быть изменен без обратной совместимости, или популярность может уйти к еще более удачной ФС, инструментарий пропадет из актуальных сборок. И то, что SquashFS происходит (насколько я понимаю) из динамичной линуксовой экосистемы, в которой бытует свое избирательное отношение к обратной совместимости, эти опасения лишь усиливает. Понятно, что полностью застрахованы от устаревания разве что какие-нибудь стандарты ISO вроде zip или docx.

А почему тогда не использовать тот же 7z? Получается и сжатие хорошее и быстрый доступ к содержимому без затрагивания ядерных механизмов монтирования и поддержки файловых систем.

Что мешает использовать SquashFS вообще везде, где раньше был TAR?

Наличие более простых и удобных архиваторов вроде 7z

Тогда уж RAR, у которого есть полезная для архивного хранения функция восстановления поврежденных файлов (по мотивам замечательного треда Все unix-компрессоры -- говно?).

У обоих есть некоторые второстепенные недостатки: не сохраняют права доступа (не обязательно для архива, но критично для бэкапа), далековаты от мейнстрима (созданы и развиваются энтузиастами)… Я для себя не отбрасываю окончательно и этот вариант, но смущает ограниченная популярность.

Тогда уж RAR, у которого есть полезная для архивного хранения функция восстановления поврежденных файлов

Вы хотите купить лицензию? И уверены, что через 20 лет rar все еще будет продаваться? И доверите свои данные архиватору без исходных текстов?

squashfs в плане удобств сейчас наилучший выбор для линукса.
Рошал так и не допилил поддержку *никса в раре, а жаль. получился бы наифункциональнейший комбайн.

в squashfs бекаплю корневую файловую систему и все остальное помаленьку. намного функциональнее каменного топора тар, из которого во все стороны торчат давно проржавевшие функции типа управления лентоприводом :)… но кому-то он до сих пор нравится.

+

Это не есть что-то невозможное, если бы у него были какие-то абсолютные киллер фичи. Он же не держит данные в заложниках, unrar доступен в исходниках. Но да, использовать проприетарные программы в инфраструктуре нет большого желания.

squashfs в плане удобств сейчас наилучший выбор для линукса

А что именно так привлекает, дело в файловых аттрибутах, или в чем-то еще?

Серьезно, пусть хранятся какие-нибудь «чистые» данные, например архив статей или книг, а может просто много чисел по разным файлам. Будет заметна разница между squashfs и zip/7z на больших объемах?

Он же не держит данные в заложниках, unrar доступен в исходниках

unrar имеет массу ограничений! Как минимум - unrar не поддерживает «функцию восстановления поврежденных архивов». К тому же - не может расжать многотомный архив. А держать «данные размером порядка пары сотен Гб» в одном архиве - это нарываться на невозможность копирования такого архива.

Что мешает использовать SquashFS вообще везде, где раньше был TAR?

Нельзя результат записать в поток вывода, а с tar можно удалённый сервер по ssh забэкапить.

да прикладная необходимость - полноценная поддержка *никс-метаданных :)

squashfs это контейнер, поддерживающий сжатие gzip lzma lzo lz4 xz zstd сжатие.
zip тоже применял множества форматов сжатия, zip под руками нет и влом искать какие точно.
7zip использует lzma (пока только одЫн :).

так что разница будет :), плюс все будет еще зависеть от параметров сжатия, ну и немного от реализации алгоритма.

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

sshfs спасет отца русской демократии :)
мне нравится конечно современная уверенность в качестве сети и неразрывности соединения, но предпочитаю по возможности, сжимать в локальный архив, прогонять его через тест, а уж потом доставлять на удаленку гарантированным методом хотя бы тем же rsync.
иногда лучше тридцать раз перебздеть, чем один раз обосраться…

Будет заметна разница между squashfs и zip/7z на больших объемах?

squashfs сжимает блоки по 128 килобайт независимо, ЕМНИП. 7z жмёт весь поток разом или очень большими блоками. LZMA и там и там.

Например, сделай так. И сам решишь, заметна разница или нет.

squashfs сжимает блоки по 128 килобайт

-b <block_size>		set data block to <block_size>.  Default 128 Kbytes.
			Optionally a suffix of K or M can be given to specify
			Kbytes or Mbytes respectively

https://docs.kernel.org/filesystems/squashfs.html

1МБ максимум. Еще хз как это на скорость доступа и потребление памяти влияет. Там с этим тоже свои заморочки.

хых. squashfs и не ориентировался на высокое сжатие :) это другое !111
squashfs создавался как файловая система произвольного доступа, а чем больше блок сжатия, тем дольше произвольный доступ к отдельным файлам.

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

Я выше упомянул DwarFS, который используется в Conty от Kron4ek. Так там можно блок выставить до 64 Mb.

Кстати, в Conty используется две разных FS, это SquashFS и DwarFS. Причем утверждается, что «Помимо лучшего сжатия, DwarFS также имеет лучшее кэширование и лучшую поддержку многопоточности, и, по моему опыту, она читает сжатые файлы заметно быстрее, чем SquashFS».

Может Kron4ek придет в тред и поделится положительным опытом использования DwarFS. А также выскажется на счет идеи использовать его в качестве архива данных, вместо SquashFS.

Тогда уж RAR, у которого есть полезная для архивного хранения функция восстановления поврежденных файлов

Может, всё-таки стоит разделять надёжность хранения (zfs) и компрессию (архиватор)? А не делать странный комбайн, кладя все яйца в одну корзину?

DwarFS лучше почти по всем фронтам: он и быстрее чем squashfs, и жмет лучше, и всяких настроек в нем куда больше, и размер блока можно больше 1 MB выставить (вплоть до 1GB), есть dwarfsck для проверки целостности файловой системы (у squashfs вроде подобного нет?). Проблема однако в том, что его нет в репозиториях многих дистрибутивов, нужно самому компилировать или качать статические бинарники с github. И еще, в отличие от squashfs, у dwarfs нет ядерного драйвера, только FUSE, если это кому-то важно.

Впрочем, в данном случае, учитывая что ТСу степень сжатия не особо важна и если хранить контрольные суммы файлов отдельно, принципиальной разницы нет, что использовать.

надежность хранения формируется правилом 3-2-1 и еще многими составляющими, в коих зфс занимает свое небольшое узко-локальное место. если возникнет к примеру пожар и сервер сгорит то все крутости зфс помахают всем бекапам известным влажным местом :)
даже если я впихну бекапы в простенький распределенный syncthing на нескольких географически раскиданных обычных компуктерах, то надежность данного решения будет выше :)

комбайн удобен, когда часто требуемые вместе функции упакованы в один удобный инструмент. т.е. в плане бекап/архивов, согласись, обычно применяется сразу вся связка сериализатор+сжиматель+шифратор+восстановитель.
когда необходимые инструменты в одной корзине очень удобно их вместе использовать.
если займешься авторемонтом, то тебе удобнее будет пользоваться удобным ящиком с инструментами все-в-одном, чем бегать по большому цеху, в одном конце которого хороший сверлильный станок и в другом хороший пилильный :)

если возникнет к примеру пожар и сервер сгорит то все крутости зфс помахают всем бекапам известным влажным местом :)

А если в Землю прилетит метеорит, то надо бэкапиться на Луну или Марс, да :)

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

Для разработчика, который хранит старые проекты размером по сотни гигабайт в течение 10 лет, отдельная хранилка с zfs (и бэкапом в другую локацию) - must have. Никакой rar это не заменит.

абсолютно согласен :)
вот холодный бекап в другую локацию (даже на антресоль) аккурат и удобен в рар-архиве.

• тут тебе и обалденное сжатие - меньше места занимает. у меня 2 гиговая папка с pcb ужимается до 40 мб. сжатие в 42(!) раза.
• и шифрация (а фдрух украдут)
• и наличие восстановления ошибок. записал на диск, ленту, м-диск и закинул в дальний ящик на десятилетия хранения. даже ежели чего начнет разваливаться - есть вероятность восстановить.
  он таки именно для ентого и создавался :)

а вот зфс создавался именно как рабочая файловая система. и отлично работает как рабочая файловая система.

разделяй и властвуй.

чегойто мы от темы сильно отдалились…

Про DwarFS я тут первый раз услышал. Можно попробовать потыкать.

Оно внезапно не на Go. Даже интересно стало.

Languages

    C++ 96.7%
    CMake 1.8%
    Other 1.5% 

У разраба в Releases есть бинарные сборки со статическими либами. Должны работать во всех дистрах, по идее.

В AUR есть пакеты, не знаю как в других дистрибутивах.

Тогда дело серьезное, почему-то думал что он умеет и восстанавливать.

Я согласен, что лучше быть здоровым и богатым, но сколько стоит лишний RAID? – это очевидно несколько дисков плюс машина, в которую они воткнуты. На шкале важности данных есть диапазон, когда еще не хочется заводить вторую копию, но уже есть желание положить рядом PAR2 или запаковать в RAR. Есть следующий диапазон, когда уже пора бы завести второй внешний диск, но отдельный сервак с развернутой ZFS это пока еще перебор.

Домашний NAS - это не только хранилка подобных бэкапов, но и хранилка любых бэкапов, фотографий, качалка, смотрелка по dlna, умный дом, домашняя лаба с виртуалками и ещё 100500 различных примемений.

Если исключить «домашняя лаба с виртуалками», то подойдёт любой целерон атомный.

Я не понимаю домашнего NAS. В чём смысл хранить бэкап на расстоянии трёх метров от источника бэкапа?

1. Авария в электросети, выжигающая всю электронику - такой бэкап не спасёт
2. Пожар - такой бэкап не спасёт
3. Потоп - такой бэкап не спасёт
4. Обнос квартиры - такой бэкап не спасёт

Более того, глядя вокруг, могу сказать, что люди покупают или делают NAS’ы, прежде всего, чтобы повозиться, как хобби. И через 2, 3, 4 года выключают их и забрасывают на антресоли, ибо они достают своим непрерывным гудением, а практической пользы от них почти 0.

Я не понимаю домашнего NAS. В чём смысл хранить бэкап на расстоянии трёх метров от источника бэкапа?

Ты просто не умеешь его готовить!
Кто сказал, что NAS только для бэкапов? У меня, кроме бэкапов, там еще небольшая коллекция видео (понравившиеся сериалы), немного музыки, немного книг (старая копия lib.rus.ec), коллекция дистрибутивов Линукс в виде iso-файлов, репозиторий пакетов обновления текущего Линукса (не качать же 3-4 раза одно и тоже при обновлении нескольких буков). И все это постоянно доступно с любого домашнего компа (а также с ТВ и аудио-ресивера).
Ну и плюс - эксперименты с NAS, для тренировки навыков админа домашней сетки.