В выпуске Fedora 42, намеченном на конец апреля, планируется перевести все Live-сборки дистрибутива со SquashFS на файловую систему EROFS, поддержка которой в прошлом году была реализована в инструментарии для создания загрузочных образов Dracut 103. Предложение пока не утверждено комитетом FESCo (Fedora Engineering Steering Committee), отвечающим за техническую часть разработки дистрибутива Fedora...Подробнее: https://www.opennet.me/opennews/art.shtml?num=62566
Интересует поддержка атрибутов файлов в этих ФС: ACL, XATTR, ATTR.Лично, для Live CD/DVD/BD, выберу ФС с большим сжатием и лучшей поддержкой атрибутов.
Скорость ФС при чтении с CD/DVD/BD неважна.
> Лично, для Live CD/DVD/BD, выберу ФС с большим сжатиемТы новость читал? О каком выборе ты говоришь, если его не будет:
> планируется перевести все Live-сборки дистрибутива со SquashFS на файловую систему EROFS
или ты не в контесте новости флудишь?
— Петрович, их читать учат?
— Учат. Но в контексте.
Выберу, в контексте создания своего Live CD/DVD/BD, предлагаемый вам выбор федорки не интересует.Глянул https://www.kernel.org/doc/html/latest/filesystems/squashfs....
SquashFS не умеет ACL, ATTR и с нее диверсанты выкинули возможность сортировки файлов, что важно для скорости чтения с привода гораздо больше чем скорость ФС. Также сортировка важна для создания воспроизводимых образов squashfs.
EROFS гляну если у нее будет: воспроизводимость, ACL, ATTR, XATTR.
Squashfs умеет создавать ФС из tar, в том порядке файлов, каковы они в tar.
Лет 5 назад захотелось сделать воспроизводимый бит в бит LiveDVD. Пропатчил emerge и genkernel для создания воспроизводимых пакетов и ядра с инитрамфс. Получил воспроизводимый staage3. А вот ФС и загрузчик воспроизводимый получить не удалось.Сортировка файлов в архиве, на ФС необходима для воспроизводимости.
Скорость загрузки LiveDVD и строк службы привода можно значительно увеличить разместив файлы в squashfs в том порядке в котором они читаются при загрузки OS. Жаль что эту нужную фичу выкинули с squashfs.
CD/DVD/BD : UDF, NIX-атрибуты поддерживает.
воспроизводимость, ATTR, XATTR поддерживает?
Ты всё ещё пользуешься лазерными дисками всерьёз, а не как метафору?> Скорость ФС неважна
Это всегда зависит от контекста же. Где-то нужна, где-то нет. Если Live USB используется, чтоб потрогать дистр, то вообще ничего не нужно максимизировать. Если для установки, особенно автоматической и массовой, то вполне себе важный параметр.
Да пользуюсь лазерными дисками и альтернативы не вижу. Знаешь альтернативу сравнима по цене и времени хранения данных расскажи.Привод читает диски всегда медленнее чем работает ФС. Да ISO l-шку можно проигнорировать локально с ro,loop тогда на скорость будет влиять ФС, но это редкость для Live CD//DVD/BD.
> Да пользуюсь лазерными дисками и альтернативы не вижу. Знаешь альтернативу сравнима по
> цене и времени хранения данных расскажи.5-10 лет по цене ~$32/TB? Любой хард, не?
10 лет хороший хард на магнитных дисках должен держать данные, не SRM, не гелиевые.
до 5 лет хороший SSD.Производители хороших DVD 4.7Gb за <50 рублей дают 100 лет сохранности данных
BD M-disc обещает 1000 лет.
Project Silica на 7Tb диск с кварцевого стекла, размером как стандартный DVD, обещает минимум 10000лет сохранности данных.Если банально хочется хранить фотки и видео с отпуска 50-100 лет, то альтернативы оптическим дискам для обывателя нет.
> BD M-disc обещает 1000 лет.Обещать - не значит жениться. Кто ж проверять будет? И кстати, где через 1000 (или 50) лет приводы брать - они ведь тоже не вечные?
Да и с ценой на M-диски выходит совсем не $32/TB, а где-то 100-120/TB.
Пока оптические приводы поддерживают и старые диски. Да, возможно, через 50 лет придется с BD все переписать, на новые. Как сегодня с CD/DVD переписывают на BD.
А может и сегодняшние DVD/BD будут доступные приводы и через 100 лет читать.
> Пока оптические приводы поддерживают и старые диски.Однако через несколько лет у них пылится оптика и/или садится лазер и они в лучшем случае читают со скрипом. Так что бэкап может и не прочитаться.
Кроме того есть такая штука как disc rot и записываемые, и особенно низкокачественные перезаписываемые болванки - выцветают в момент. Хотя обещали тоже дофига лет. А на практике у половины окислился отражающий слой, выцвел краситель, или еще какое-то барахло.
...а вот жесткие диски штуки довольно стабильные так то, и неплохо хранятся. Винч 1998 года до сих пор живой. То что его емкость - в пару сидюков - другой вопрос уже.
Слабыми местами оптических приводов считают пластиковую линзу, флеш для хранения прошивки и механику при использовании. Это все равно десятилетия.
> Слабыми местами оптических приводов считают пластиковую линзу, флеш для хранения прошивки
> и механику при использовании. Это все равно десятилетия.NOR флеха в CD/DVD накопителе - таки - проживет годиков под 50-100 при комнатной температуре, а вот из сидюков эти сто лет протянет разве что старинная, качественная штамповка. Что бесполезно для бэкапов от слова вообще.
У более дешевых у кого отражаюзщий слой окисляется, у записываемых краситель превращается в тыкву более 9000 способами, и читается это через цать лет - от голимо до никак.
Про кварцевое стекло и, совершенно избирательно, конкретный проект - лучше даже не упоминать. Мало того, что они далеко не первые кто додумался работать со стеклом/плавленым кварцем. Так ещё и нет никакой гарантии, что с их носителей инфу можно будет прочитать хотя бы лет через 10-20.
Выкинут стартап на помойку как не окупившийся - и дело с концом. Сам потом для тех пластин читалки изобретать будешь ?
Где связь между хранением данных и live сборками ОС?
>>ACL, XATTR, ATTRВы еще RockRidge-extensions вспомните :).
Это в ISO, им пользовался тоже. Теперь пока все tar --acls --xattrs упаковываю. А для ATTR пишу и ложу отдельный скрипт, tar его не поддерживает.
> По сравнению со SquashFS в EROFS ниже уровень сжатия (2.0 GiB против 2.7 GiB для XZ и 3.1 GiB против 3.9 GiB для LZ4),Вот те и новые фичи - место на флешке/сидюке сильнее жрет.
> но более высокая скорость доступа (5.0 MiB/s против 7.1 MiB/s для XZ и 26.3 MiB/s против 30.9 MiB/s для LZ4)
Как эти системные эксперты такую зашакаленную скорость LZ4 вообще получили?! Он же даже на коре дуба делает гигабайты в секунду сам по себе?!
наверное очень классная флешка с алика, я недавно тестил чтение sqfs с образов в озу, xz - 200мб/с, zstd что-то около 1500, ddr5-5200
Ты не учел что фс хуавея отправляет данные лично товарищу Си.
Диверсифицированные инженеры федоры.
Накрутки китайцы из хуавея.
> Диверсифицированные инженеры федоры.Системная диверсия у них получилась неплохо.
В новых ядрах для EROFS добавили алгоритмы сжатия DEFLATE и zstd, а в SquashFS вроде не добавили. Поэтому сравнивают только одинаковые алгоритмы в обоих файловых системах.
squashfs уже двести лет gzip и zstd поддерживает.
Спасибо, не знал. Смотрел статьи сравнения Squashfs с EROFS и в статьях почему-то никогда не приводят zstd, думал его нет в обоих ФС. Теперь есть в обоих.
>SquashFSСталкивался. Вроде прикольная идея, а потом мне понадобилось внести изменения в парочку файлов. А архив был гиг на 20-30.
Возможности override файлов я не нашёл, хотя казалось бы.
Для этого есть OverlayFS.
"утилита делает одно и делает это хорошо"
что эро что сквош делают сжатую р/о фс и не мудрят с каскадированием.
каскадирование делают соответвующие утилиты.
Для сжатия уже есть dm-vdo, поэтому EROFS нарушает твой принцип. И напомни-ка, какую файловую систему по умолчанию использует десктопная Fedora, раз достаёшь принципы из широких штанин.
> Для сжатия уже есть dm-vdo, поэтому EROFS нарушает твой принцип. И напомни-ка,
> какую файловую систему по умолчанию использует десктопная Fedora, раз достаёшь принципы
> из широких штанин.Для live - squashfs внезапно. Это несколько другой случай чем инстальнутая копия на харде, особенно если реально на болванку закатано.
Зачем повторяешь заголовок новости?Я про то, где федора видела принципы фанатов unix way последних дней. Она использует btrfs.
Повторять OverlayFS в SquashFS не нужно, но функциональность в диапазоне от tar --update (о нет, tar делает вторую вещь) до wimlib'овской пригодилась бы.
> Сталкивался. Вроде прикольная идея, а потом мне понадобилось внести изменения в парочку
> файлов. А архив был гиг на 20-30.С таким аппетитом - можно btrfs с read-only снапшотом юзать. А если ну вот капец как надо стало - можно с него readonly таки, на время, снять, померять пару файлов, и вернуть readonly флаг на место.
Но, конечно, он ни в раз не такой же компактный как вон те, особенно squashfs. Squashfs вообще делался - с прицелом на максимальную компактность при каком-никаком рандомном доступе. Он между обычными фс и архивами по смыслу.
Оно не совсем для этого. Оно, типо, для выпуска конечных версий разных модулей, сборок или плагинов. Вместо папки с кучей мелких файлов получается один файл, ещё и архив, ещё и только для чтения
Потребовалось что-то изменить - выпускаешь новую версию
Управляющие пакетом livecd-tools в каждом релизе Fedora не успевают в гонке за новшествами пайтона. Каждый релиз начинается с рабочей композиции, а потом сразу поступают обновления к этому "питону" и.. сплошные ошибки при создании live.
Теперь, значит, ещё один "развивающийся" фактор добавить хотят. К гадалке не ходи, вся эта автоматизация создания live, основанная на пакете livecd-tools, уйдёт в позабытое прошлое.
Может для Live-режима использовать режим copy to ram и после наслаждать скоростью работы?
А уж как приятно наслаждаться скоростью загрузки будет.
> А уж как приятно наслаждаться скоростью загрузки будет.Knoppix довольно быстро грузится в память, а вот у вас после каждого чиха тормоза обеспечены.
А ларчик просто открывался: EROFS прд двойной лицензией (GPL/Apache), а Squashfs — исключительно GPL.