По скорости обращения к данным DwarFS примерно находится на том же уровне, что и SquashFS, но в разы опережает данную ФС по эффективности сжатия и скорости формирования образа.
Создание образов осуществляется утилитой mkdwarfs, а монтирование утилитой dwarfs.Т.е. чем создать и чем примонтировать есть
clang bison flex libevent sparsehashПапки не склеены:перезалил dwarfs-0.2.1_64-2008-sf02.pfs (http://mirror.yandex.ru/puppyrus/roll/2008/pfs-test/dwarfs-0.2.1_64-2008-sf02.pfs)
live@pra-roll:~$ ls -l /mnt/live/memory/images/dwarfs-0.2.1.dfs
ls: невозможно получить доступ к '/mnt/live/memory/images/dwarfs-0.2.1.dfs': Отказано в доступеОтказано в доступеdfs ---> pfs
Или это намеренно так сделано?Да, модуль .dfs (https://yadi.sk/d/ZsH48PQR_mA4SQ)
"DwarFS - замена squashfs" утверждение спорное.Это был вопрос, а не утверждение
Сжатие по умолчанию ~1,5 раз больше, но в ~4 раза медленнее.Такое было бы интересно
"рядом" монтирует, а "по месту" получается нечитабельная точка монтирования.Не понял - можно подробнее...
Основной минус - придётся тащить dwarfs в initrd со всеми зависимостями (~6Mb в оптимизированном варианте). Оно надо?Если размер дистра уменьшится в 1,5 раза - оно того стоит (если получится сделать слоем aufs)
требуются какие-то дополнительные либы. Не удивлюсь, если половина перлаСамый жирный boost. Перла и питона нет
Пока лучший вариант - понаблюдать.В большом линуксе уже и AUFS почти выкинули. Боюсь ничего для фругала не дождемся. Придется самим
Не понял - можно подробнее...Создал точку монтирования mntpt рядом с dwarfs-0.2.1.dfs и успешно примонтировал командой "dwarfs dwarfs mntpt". Эти действия произведены на разделе sda3. А вот "куда надо" не примонтировалось. Создал точку монтирования /mnt/live/memory/images/dwarfs-0.2.1.dfs и примонтировал с полными путями. Получил битую точку монтирования.
Что делали - что получили
В большом линуксе уже и AUFS почти выкинули.А оно им и не нужно. Куда в full можно применить aufs? Никуда!
Сжатие по умолчанию ~1,5 раз больше, но в ~4 раза медленнее.Действительно, оооочень долгий процесс. Сначала сканирование идет, добавляя время, потом сжатие тоже не быстрое.
$ sudo du -sh /mnt/sda3/funtoo
4,2G /mnt/sda3/funtoo
$ du -sh funtoo.pfs
728M funtoo.pfs
$ du -sh funtoo.dwarfs
633M funtoo.dwarfsmkdwarfs --- zstd -Xcompression-level 22.Xz нельзя? Может, еще больше сожмется. Хорошо бы еще скорость чтения из сквоша и dwfs сравнить
умеет ли mkdwarfs в многопоточностьПосмотрите htop - если в процессе сжатия все ядра равномерно загружены = умеет
dwfs + aufsНе хочет...
Куда в full можно применить aufs? Никуда!initrd, docker
Есть идеи?Какие могут быть идеи, если точка монтирования dwarfs получается битая.
Скорость сжатия не критичнаУ него железо:
Эти тесты проводились на 6-ядерном процессоре Intel (R) Xeon (R) D-1528 @ 1,90 ГГц с 64 ГиБ ОЗУ.И командой time mkdwarfs -i install -o perl-install.dwarfs (-comp zstd -Xcompression-level 22) он все сжал за:
Исходный каталог содержал ... всего 47,65 ГиБ данных... каталог был недавно распакован из tar-архива на SSD 850 EVO 1 ТБ....
всего 47,65 ГиБ данныхПричем он сжал до безумных размеров:
compressed filesystem: 450 blocks/555.7 MiB written
12:56:46.116043 finding duplicate files...
12:56:46.133114 saved 6.897 MiB / 415 MiB in 2833/14289 duplicate files
mkdwarfs --help
9 24 lzma:level=9:extreme zstd:level=22 lzma:level=9:extreme 17,15,13,11
-N [ --num-workers ] arg (=4) number of writer worker threads
-M [ --max-scanner-workers ] arg (=4) number of scanner worker threads
Какие могут быть идеи, если точка монтирования dwarfs получается битая.Это не то?
Version 0.2.3 - 2020-12-01
Fix link handling. There were two bugs introduced with the new metadata format, one in file system creation and another in the fuse driver. You will have to re-create a file system created with dwarfs < 0.2.3 if it contained links. If you can absolutely not re-create the file system and the data is precious, let me know, there's actually a way to recover the missing data.
Исправить обработку ссылок. В новом формате метаданных было обнаружено две ошибки: одна при создании файловой системы, а другая - в драйвере fuse.
Version 0.2.2 - 2020-11-30
Remove read-only masking as it prevents writable overlays
Throw an error in mkdwarfs if unrecognized command line arguments are encountered (github #5)
Various build fixes (github #2. #3)
More documentation
Наверно фишка mkdwarfs за счет оптимизации дубликатов?В squashfs это тоже есть (2 одинаковых файла в офном сквоше займут места как 1 )
Есть ещё и посекторная дедубликация на BTRFS и OpenZFSНужны цифры в сравнении с тем, что мы тут тестируем
это одинаковый размерПри эксперименте с монтированными модулями PRA - да, при упаковке фулл (funtoo 4,2Gb) - выигрыш около 100Mb, при дефолтных mkpfs и mkdwarfs.
Тот что с aur, у меня с ошибками.Не скомпилился или скомпилился , но не работает?
На мой взгляд это дало бы толчок развитию фругала на пользовательском уровне (самостоятельные сборки). Способность быстро, за считанные минуты, сжимать в pfs/dfs большие объемы данных...Не замечал такой проблемы. Где у нас объемы... У нас "маленький и быстрый"
выигрыш в данном примере 10MbТогда не особо впечатляет. Надо ли вообще...
$ sudo du -sh /mnt/sda3/funtoo
4,2G /mnt/sda3/funtoo
$ du -sh funtoo.pfs
728M funtoo.pfs
$ du -sh funtoo.dwarfs
633M funtoo.dwarfs
Размер после сжатия впечатляет.
выигрыш в данном примере 10MbУчитывая, что этот тест был на одном модуле, а в том же PRA-roll-20.08-7 их 35.
Тогда не особо впечатляет. Надо ли вообще..
Странная логика.Сначала не догнал, что 100мб экономии - это 10%
Алгоритм сегментации был полностью переписан и теперь намного чище, использует гораздо меньше памяти, значительно быстрее и обнаруживает намного больше повторяющихся сегментов. В то же время его проще настроить (просто размер одного окна вместо списка).https://github.com/mhx/dwarfs/releases/tag/v0.4.0
...степень сжатия также значительно улучшилась, в основном за счет нового алгоритма сегментации. В выпуске 0.3.1 с использованием конфигурации по умолчанию 47 ГиБ установленных Perl были сжаты до 471,6 МиБ. В выпуске 0.4.0 этот показатель упал до 426,5 МБ, что на 10% больше . Используя lzmaсжатие ( -l9), размер результирующего изображения уменьшился с 319,5 МБ до 300,9 МБ, что примерно на 5% лучше . Что еще более важно, размер несжатой файловой системы снизился с 7 ГиБ до 4 ГиБ благодаря улучшенной сегментации, что означает, что меньше при использовании файловой системы в среднем требуется распаковывать блоков.
...
Сравнивал mkpfs /mnt/sda3/funtoo и mkdwarfs -i /mnt/sda3/funtoo -o funtoo.dwarfsКод$ sudo du -sh /mnt/sda3/funtoo
4,2G /mnt/sda3/funtoo
$ du -sh funtoo.pfs
728M funtoo.pfs
$ du -sh funtoo.dwarfs
633M funtoo.dwarfs
Одна из особенностей последних релизов - наличие в архиве бинарника, не требующего сторонних либ.
Разработчики Arch Linux сообщили о переводе схемы упаковки пакетов с алгоритма xz (.pkg.tar.xz) на zstd (.pkg.tar.zst). Пересборка пакетов в формат zstd привела к суммарному увеличению размера пакетов на 0.8%, но обеспечило ускорение распаковки на 1300%. Как следствие, переход на zstd приведёт к заметному увеличению скорости установки пакетов.https://www.opennet.ru/opennews/art.shtml?num=52139
За dwarfs будущее.Из чего сделан этот вывод?
Погуглил - кроме нас никто не заинтересовалсяЧто-то изменилось?
Толстая
статический пакет от автора, не требующий зависимостей.В собранном пакете из aur (https://aur.archlinux.org/packages/?O=0&K=dwarfs), весит 1.7 mb.
весит 1.7 mbДля initrd всё равно много.
bash-4.4$ du -h minitrd.gz
192.0K minitrd.gzДля initrd всё равно много.:)
52,1 mbПомнится slitaz был целиком (с де и т.п.) в инитрд и весил меньше :)
Section index support for speeding up mount times (fixes #48 (https://github.com/mhx/dwarfs/issues/48)).
Changelog:https://github.com/Kron4ek/Conty/releases/tag/1.19.7
....
DwarFS теперь включает улучшения .... и теперь монтирует образы практически мгновенно даже на медленных HDD. Поэтому, если вы избегали использования DwarFS из-за медленного времени монтирования, вы можете попробовать его прямо сейчас.
conty_dwarfs.shа также conty_lite_dwarfs.sh такие же, как и обычные версии, за исключением того, что они сжаты с помощью DwarFS вместо SquashFS, поэтому занимают меньше места на диске.https://github.com/Kron4ek/Conty/releases/tag/1.21.1
Помимо лучшего сжатия, DwarFS также имеет лучшее кэширование и лучшую поддержку многопоточности, и, по моему опыту, она читает сжатые файлы заметно быстрее, чем SquashFS (в частности, squashfuse). Однако преимущество squashfuse в том, что он использует меньше памяти.