https://opennet.me/openforum/vsluhforumID3/122555.html Маркус Холланд-Мориц (Marcus Holland-Moritz) из компании Facebook опубликовал первые выпуски файловой системы DwarFS, работающей в режиме "только для чтения" и нацеленной на обеспечение максимального уровня сжатия и сокращения избыточных данных. ФС использует механизм FUSE и работает пространстве пользователя. Код написан на С++ и распространяется под лицензией GPLv3...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=54166<br> https://opennet.me/openforum/vsluhforumID3/122555.html#79 Sun, 11 Jun 2023 15:57:40 GMT Особенно приятно что багов немного и они оперативно закрываются<br>https://github.com/mhx/dwarfs/issues<br> https://opennet.me/openforum/vsluhforumID3/122555.html#78 Tue, 08 Dec 2020 16:14:57 GMT Это вы просто не видели компрессоров которые пакуют 100 килобайтов порядка часа на core i7.<br> https://opennet.me/openforum/vsluhforumID3/122555.html#77 Tue, 08 Dec 2020 06:57:07 GMT Скорость формирования образа тут зачем?? Скорость и уровень сжатия всегда идут в компромиссе. <br>И в решении 1 раз сжал - миллион раз используй - как бы вообще скорость смысла не имеет. <br> https://opennet.me/openforum/vsluhforumID3/122555.html#76 Thu, 03 Dec 2020 10:04:20 GMT &gt; Про LZ4HC что-то слышал, ламерок?<br><br>еще lz4ultra вспомните, блин... а таки сколько LZ4 не жми, LZMA он не станет<br> https://opennet.me/openforum/vsluhforumID3/122555.html#75 Thu, 03 Dec 2020 10:02:42 GMT Так жмите LZO каким или LZ4, тогда может даже ускориться - за счет того что читать меньше. Они распаковываются со скоростью сотни мегов а то и гигабайты в секунду, и при том скрипты неплохо сожмут, раза в 2-3 запросто.<br><br>На SSD это оправдано экономией места, которое стоит денег, при том не особо мало, особенно на хорошем SSD а на бросовой сыпучке TLC.<br> https://opennet.me/openforum/vsluhforumID3/122555.html#74 Thu, 03 Dec 2020 09:59:54 GMT Да какой же правильный? С C++ и фузом он будет тормозной и squashfs при всем желании не заменит.<br> https://opennet.me/openforum/vsluhforumID3/122555.html#73 Wed, 02 Dec 2020 20:20:26 GMT 7z (2016 года правда) со словарём в половину объёма данных (как раз влезет целиком после дедуплекации) и ms=on кстати победил, и я так понимаю все данные были эффективно дедуплицированы и сжаты (ценой памяти и времени), но это работает только там где файлы крошечные. Ну т.е. реалистично в пределах гигабайта может быть, больше словарь делать будет проблематично. При словаре 512mb файл получился на 1 килобайт меньше чем со словарём 256mb. Чтобы это проверить, пожал также со словарём в 4 раза меньше чистых данных (64mb) и архив получился больше в 4 раза, одинаково с tar-xz. Т.е. моя изначальная версия по поводу размера словаря и эффективности работы верна: там где нет возможности поместить все данные в окно словаря в памяти, zpaq выходит на первое место по качеству и эффективности сжатия, в остальных случаях лидирует 7z. Можно конечно и xz попробовать с нестандартным словарём, наверное тоже будет работать (если он может словарь больше 64).<br> https://opennet.me/openforum/vsluhforumID3/122555.html#72 Wed, 02 Dec 2020 19:55:35 GMT Да, zpaq хорош, даже +- дефолтный и памяти почти не использовал. Я уверен, можно получше параметры подобрать. Вот что он имеет сказать по поводу нескольких слегка модифицированных файлов <br><br>496.599686 MB of 496.599686 MB (23605 files) shown<br> -&gt; 201.919396 MB (29465 refs to 7312 of 7312 frags) after dedupe<br> -&gt; 34.364011 MB compressed.<br><br>Отработал он при этом в 100 раз быстрее сжатия tar.xz и файл в 4 раза меньше.<br><br>squash намного лучше справился, но тоже <br><br>---- xz:<br>Filesystem size 46834.48 Kbytes (45.74 Mbytes)<br> 9.62% of uncompressed filesystem size (486725.90 Kbytes)<br>Inode table size 172470 bytes (168.43 Kbytes)<br> 22.34% of uncompressed inode table size (771926 bytes)<br>Directory table size 124890 bytes (121.96 Kbytes)<br> 14.92% of uncompressed directory table size (836937 bytes)<br>Number of duplicate files found 18436<br>---- gzip-9:<br>Filesystem size 58716.29 Kbytes (57.34 Mbytes)<br> 12.06% of uncompressed filesystem size (486725.90 Kbytes)<br>Inode table size 213849 bytes (20 https://opennet.me/openforum/vsluhforumID3/122555.html#71 Tue, 01 Dec 2020 18:31:01 GMT Можешь попробовать fuse-overlayfs для того, чтобы спокойно менять при необходимости.<br>