Маркус Холланд-Мориц (Marcus Holland-Moritz) из компании Facebook опубликовал первые выпуски файловой системы DwarFS, работающей в режиме "только для чтения" и нацеленной на обеспечение максимального уровня сжатия и сокращения избыточных данных. ФС использует механизм FUSE и работает пространстве пользователя. Код написан на С++ и распространяется под лицензией GPLv3...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54166
На ленты можно будет накатить. Хотя, там уже сами LTO-приводы, вроде, делают своё сжатие.
не представляю как можно сжимать для устройства с линейным доступом, кроме как gzip/bzip2/xz или аналогов, ну в общем блок потока. ведь что-то выиграть на дедупликации внеблока нельзя, а это и есть самое выгодное для файловой системы.
Вот кстати единственный архиватор, который занимается дедупликацией (помимо того что позволяет выбрать эффективные фдля контента фильтры, мог бы и сам озаботиться конечно) это zpaq. Больше никто дидуплекацию не делает — у тебя в файле будет несколько копий одних и тех же данных в итоге. Даже если файлы совершенно идентичные, архиваторы недостаточно умные, чтобы угадать идентичность по хэшам. Про потоковые и говорить нечего, конечно.
Squashfs вроде обещала дедупликацию, но я её не заметил что-то совершенно.
Пофайловая есть. Одинааовые файлы сгребает еще до отправки на сжатие, можешь чекать статистику в клнце mksquashfs
Не знаю, я сжимал 2 копии одинаковых файлов лежащих рядом (они не рядом с точки зрения архиватора, файлов было много) и ни архиваторы ни squash и приблизиться не смогли к zpaq (по времени у того сравнимо с 7z, примерно одинаково даже).
7z кстати при этом сжал почему-то лучше squashfs (там xz компрессором был).
Можно перед mksquashfs прогнать любой дедупликатор, заменяющий копии на симлинки
Зачем, если и так есть файловая дедубликация? Блочной нет.
>архиваторыПри чём тут архиваторы? Архиваторы архивирут, а не сжимают.
Так и мне нужна ДЕДУПЛЕКАЦИЯ, а не СЖАТИЕ. Это задача АРХИВАТОРА, а не КОМПРЕССОРА.
exdupe и сжимает и дедуплицирует и с космической скоростью. Есть правда минус чтобы сильно сжать нужно много оперативы. Но скажем сжать пару ТБ архивов msSQL сможет на ура. (в до 10-20 раз может ужать)Есть дифы. Давное не обновлялся. И есть аналоги может даже где-то лучше. (скорее всего уже точно есть в чем-то лучше)
> архиватор, который занимается дедупликациейUse Unix way, Luke.
fdupes; tar
Каждый при своём деле.
А если мне нужны несколько копий повторяющихся данных? Допустим, медиафайлы (и даже бинарники) одинаковые, а скрипты и переводы могут отличаться. Я конечно использую hardlink, но он просто выкидывает мета-информацию о файлах и если perl-hardlink позволял выбрать по дате или размеру какой файл оставить, то utillinux-hardlink выбирает самостоятельно и случайно? Ну, зато работает быстрее. А если файлы отличаются на пару байт (очень типичная ситуация), то он уже не дедуплицируются. По этой причине я хочу попробовать дедупликацию в btrfs для решения данной задачи, но btrfs до сих пор не поддерживает case-insensitive флаг (а значит только ext4 и вроде f2fs).
Чьёрт подъери. "case-insensitive флаг" только ввели, а это стало киллер-фичей. На винду дуй, там это нормой является. Не нужно hardlink использовать, есть --reflink=(auto|always) опция для cp, mc умеет. Кстати, не только btrfs, ext4/xfs/что-там-еще-что-я-не-видел-никогда.
"А если файлы отличаются на пару байт (очень типичная ситуация), то он уже не дедуплицируются." - это к окулисту, он до 19 работает. Если ПО не умеет в ioctl_ficlonerange/ioctl_ficlone, то дедап должен выполняться сторонними средствами, к коим и ФС относится.
>На винду дуйА что мне ещё сделать?
>Не нужно hardlink использовать, есть --reflink=(auto|always) опция для cp, mc умеет
Но ведь мне не нужно копировать файлы, мне нужно их удалять. Алло.
>Если ПО не умеет в ioctl_ficlonerange/ioctl_ficlone
Какое ещё ПО, вот у меня 2 файла с песенками, отличается только дата тагирования, всё. Дальше что?
"мне нужно их удалять" - вот и удаляй. "отличается только дата тагирования, всё. Дальше что?" - ой, всё! :) Дуй на винду и храни тэги в ntfs потоках, блочные фс не умеют разницу в пару байт обрабатывать. А ты, кстати, в курсе, что винда умеет в транзакции для ntfs? Просто вопрос.
Не совсем, дедупликацию еще как минимум rar5 умеет, со своими тараканами, куда без этого. А так-то, если в словарь(в общем, не придираться) все вмещается, любой архиватор эффективно с дублями борется.
>rar5что-то не заметил (а ведь перебрал наверно все комбинации ключей), да и в целом в 5 раз хуже 7z жмёт.
>словарьа это не выход, словарь делать больше суммарного объёма данных не вариант когда у тебя гигабайты (пусть и повторяющихся данных).
У zpaq на дублирующихся данных реально в разы меньше конкурентов файл вышел.
Пардон, на работе только оффтопик и русский. Впрочем, читать документацию - это же не тру уних вей, да?"· Сохранять идентичные файлы как ссылки
Если выбран этот параметр, то перед началом архивирования выполняется анализ содержимого файлов. Если обнаруживаются несколько идентичных файлов размером более 64 КБ, первый файл из набора сохраняется как обычный файл, а все остальные — как ссылки на этот первый файл. Это позволяет уменьшить размер архива, но накладывает некоторые ограничения на результирующий архив. Первый файл из набора идентичных файлов в созданном архиве нельзя удалять или переименовывать, потому что это сделает невозможным извлечение остальных ссылающихся на него файлов. Если изменить содержимое первого файла, то при извлечении изменёнными будут и все остальные ссылающиеся на него файлы. Команда извлечения должна применяться сначала к первому файлу, чтобы остальные файлы могли быть успешно созданы.
Данный параметр рекомендуется применять только при сжатии большого количества идентичных файлов и если архив в дальнейшем не предполагается изменять, а распаковывать его вы будете полностью, без необходимости извлекать или пропускать отдельные файлы. Если все идентичные файлы достаточно малы, чтобы уместиться в словаре сжатия, то более гибкое решение, нежели данный параметр, даёт непрерывное (solid) архивирование.
Поддерживается только в архивах RAR5.
"Кстати, 7z вполне себе поддерживает, как думаете, что такое "solid block size"?
Почему ты такой теоретик? Давай сделай запрошенное, потом приходи и рассказывай, как кто-то там не умеет читать справку, угумс? Только убедись хорошенько, что заявленная "дедупликация" работает, хотя бы со словарём ну там допустим 256мб и датасетом в несколько гигабайт с дублированными данными где-то на гигабайт-полтора. Я вот знаю результат заранее.
Ок, "ты", значит ты. Я - практик, на нужных мне датасетах rar не использую, он хуже 7z lzma2 жмет. Впрочем, обхожусь gzip -3, местами -9, сжатие 20-25 кратное меня устраивает, да и процов не напасешься на моих датасетах. Расскажи, что у тебя и сколько компрессии подвергается. Я вот xml жму, в основном, 15-20 ТБ/сутки(впрочем, считал 2-3 года назад, сейчас сильно больше), с интересной латентностью.
Ни к чему выпендрёж. У меня было аж несколько различных кейсов, где размер файла имел значение — это архивирование в облако и передача по сети, и я под это заморочился выяснить как можно сжать поэффективнее. Типичная задача для меня это пожать несколько билдов для разных платформ сумарным объёмом в пределах 5-15гб, и файлы там повторяются. Когда же билдов несколько версий, количество дубликатов соответственно увеличивается весьма значительно. О чём я и говорю, архиваторы не справляются. Был ещё кейс где сколько-то терабайт текстовых данных (ну т.е. жмутся очень хорошо, ага) и дубликаты там тоже были значительным процентом. Тут понятно что только потоковое сжатие возможно, но дедупликация тоже.П.с. gzip слишком медленный и неудобный, лучше уж zstd (собственно, это предпочтительный формат, особенно когда данные придётся извлекать больше 1 раза) -- ещё бы дедуплицированный тар ему скармливать и было бы вообще прекрасно.
Вообще, это забавно, когда сильно сжатые данные занимают места больше чем почти бесплатно дедуплицированные без сжатия.
Сложно возразить. Я же не отрицаю полезность дедупликации :)
Прям уж выпендреж, не хотел, пардон, если так получилось. Да, 5-15ГБ - это же образы для ВМ, надеюсь, правильно понял? Для этих случаев имеются отдельные решения, не связаные с дедубликацией и сжатием, хотя и то и другое, несомненно, имеют право на существование. Это, скорее, проблема блочных ФС.
твой gzip жутко медленный и однопоточный
Льстец, gzip не мой :) Я умею треды использовать, однопоточность gzip тут только в плюс.
> Если изменить содержимое первого файла, то при извлечении изменёнными будут и все остальные ссылающиеся на него файлы.Что за мамкин программист прорабатывал эту логику? CoW - не, не слышал?
Это как symlink логика
exdupe еще есть (http://www.quicklz.com/exdupe/), заявляется как самый быстрый дедупликатор, но это экзотика, разработка встала. То ли вылизали идеально, то ли заброшен проект...
> exdupe еще есть (http://www.quicklz.com/exdupe/), заявляется как самый быстрый дедупликатор,
> но это экзотика, разработка встала. То ли вылизали идеально, то ли заброшен проект...Если из "заброшенного" (но вполне рабочего), то тогда уж zbackup, дает хорошую дедупликацию, неплохо конфигурируется (размер окна, сжатие), можно монтировать как ФС на чтение, можно отключить встроенное сжатие и сжимать результат. И лицензия более подходящая для форка, а не мутные "restricted and non-permissive terms".
Есть еще rdedup (на том самом ЯП, который-нельзя-называть, начинается на r, кончается на ust). По эффективности пожалуй лучше zbackup будет (тыкал где-то год назад, но у меня все упирается в IO) и на мой вкус слишком комбайнист -- встроили шифрование, поддержку облаков и прочее. Впрочем, zbackup этим (шифрование) тоже грешит.
winrar умеет в дедупликацию одинаковых файлов, нужные опции можно в мане посмотреть)
> winrar умеет в дедупликацию одинаковых файлов, нужные опции можно в мане посмотреть)Это проприетарная программа, возможно в бесплатной версии это не работает. Или в линуксовой версии это не работает. Или баг.
меня єто не останавливает!
Да, zpaq хорош, даже +- дефолтный и памяти почти не использовал. Я уверен, можно получше параметры подобрать. Вот что он имеет сказать по поводу нескольких слегка модифицированных файлов496.599686 MB of 496.599686 MB (23605 files) shown
-> 201.919396 MB (29465 refs to 7312 of 7312 frags) after dedupe
-> 34.364011 MB compressed.Отработал он при этом в 100 раз быстрее сжатия tar.xz и файл в 4 раза меньше.
squash намного лучше справился, но тоже
---- xz:
Filesystem size 46834.48 Kbytes (45.74 Mbytes)
9.62% of uncompressed filesystem size (486725.90 Kbytes)
Inode table size 172470 bytes (168.43 Kbytes)
22.34% of uncompressed inode table size (771926 bytes)
Directory table size 124890 bytes (121.96 Kbytes)
14.92% of uncompressed directory table size (836937 bytes)
Number of duplicate files found 18436
---- gzip-9:
Filesystem size 58716.29 Kbytes (57.34 Mbytes)
12.06% of uncompressed filesystem size (486725.90 Kbytes)
Inode table size 213849 bytes (208.84 Kbytes)
27.70% of uncompressed inode table size (771926 bytes)
Directory table size 156809 bytes (153.13 Kbytes)
18.74% of uncompressed directory table size (836937 bytes)
Number of duplicate files found 18436
7z (2016 года правда) со словарём в половину объёма данных (как раз влезет целиком после дедуплекации) и ms=on кстати победил, и я так понимаю все данные были эффективно дедуплицированы и сжаты (ценой памяти и времени), но это работает только там где файлы крошечные. Ну т.е. реалистично в пределах гигабайта может быть, больше словарь делать будет проблематично. При словаре 512mb файл получился на 1 килобайт меньше чем со словарём 256mb. Чтобы это проверить, пожал также со словарём в 4 раза меньше чистых данных (64mb) и архив получился больше в 4 раза, одинаково с tar-xz. Т.е. моя изначальная версия по поводу размера словаря и эффективности работы верна: там где нет возможности поместить все данные в окно словаря в памяти, zpaq выходит на первое место по качеству и эффективности сжатия, в остальных случаях лидирует 7z. Можно конечно и xz попробовать с нестандартным словарём, наверное тоже будет работать (если он может словарь больше 64).
Вечера дедупликации на опеннет
B cразу ФС городить)
С точки зрения пользователя - не интересно / "критикуешь - предлагай?" - пжалуста: ddar.
zfs + compression/deduplication
Ога, побежал разделы переформатировать)
Ссылку бы хоть оставил, а то такую имбу предложил что аж не найти
https://github.com/basak/ddar
>1139 различных установок Perl, в которых встречается 284 релизов Perlа зачем столько версий? в перле совместимость часто ломают?
>Код написан на С++ и распространяется под лицензией GPLv3.Маркус правильный пацан.
Просто фейсбук жадный
Да какой же правильный? С C++ и фузом он будет тормозной и squashfs при всем желании не заменит.
> В этом году автор нашёл время для доведению кода до публичного релиза и написание документации.Что ковид животворящий делает!!! Вот не было бы локдауна - так мир бы и не узнал.
Perl - двигатель прогресса.
*смерть перла - двигатель прогресса
В полку ФС пополнение... капец(((
Да не плачь, нормально всё.
Какая по счету и индексу ненужности фс?
Сколько шакалов из 10?
Нигде и никогда еще в мире не собиралось столько специалистов по дедупликации в одном месте.
И все они одиннаковые. Надо бы их дедублицировать.
да вы батенька технофашист.
название он выбрал не самое удачное. В гугле фиг найдёшь по не хоть что-то, всё дварфы попадаются и игры с ними...
> название он выбрал не самое удачное. В гугле фиг найдёшь по не хоть что-тоНу после такого бурного обсуждения на Опеннете теперь можно будет нагуглить уже не фиг, полтора фига!
Ну норм так, можно торренты сжимать сидировать например.
Уже давно есть всепланетная файловая ситсема, так что не нужен уже торрент.
> использует механизм FUSE и работает в пространстве пользователя
> повышение эффективности использования процессорного кэша
> очень высокий уровень сжатия
> LZ4Ненужнометр перешёл красную отметку и напоминающе звенит.
Про LZ4HC что-то слышал, ламерок?
> ламерок?Нет
> Про LZ4HC что-то слышал, ламерок?еще lz4ultra вспомните, блин... а таки сколько LZ4 не жми, LZMA он не станет
Это поможет портировать OpenWrt на старые роутеры?
Зависит от того, где OpenWrt хранит изменяемые настройки.
Хотя можно сделать сжатую файловую систему для базовых файлов; и поверх неё смонтировать UnionFS для изменяемых файлов.
Overlayfs же.
а "кластеризация похожих данных" не будет усложнять запаковку больших объемов данных в геометрической зависимости от их размера?
> обеспечивающая очень высокий уровень сжатияπfs всё равно лучше.
Я тут не давно только для себя открыл SquashFS - очень хорошо подходит для всяких скриптов кторых очень уж много в одной папка(директории). Директория node_modules в 600Мб - запаковалась в 32 Мб, и если пакеты не меняются то очень удобно ее монтировать , а тут бац и еще одна ФС появилась.....
Она очень медленная и жрёт процессор, лагает. Я наоборот пришёл к тому, что все использующиеся данные должны быть несжатыми. Это экономит и время и процессор например на ссд, на нжмд чтение могло быть заметно медленным и там это ещё оправдано -- чем меньше файлы, тем лучше.
Так жмите LZO каким или LZ4, тогда может даже ускориться - за счет того что читать меньше. Они распаковываются со скоростью сотни мегов а то и гигабайты в секунду, и при том скрипты неплохо сожмут, раза в 2-3 запросто.На SSD это оправдано экономией места, которое стоит денег, при том не особо мало, особенно на хорошем SSD а на бросовой сыпучке TLC.
Можешь попробовать fuse-overlayfs для того, чтобы спокойно менять при необходимости.
Написать код без кучи зависимостей от фэйсбучных либ он, конечно, не смог.
Скорость формирования образа тут зачем?? Скорость и уровень сжатия всегда идут в компромиссе.
И в решении 1 раз сжал - миллион раз используй - как бы вообще скорость смысла не имеет.
Это вы просто не видели компрессоров которые пакуют 100 килобайтов порядка часа на core i7.
Особенно приятно что багов немного и они оперативно закрываются
https://github.com/mhx/dwarfs/issues