Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Файловая система DwarFS, обеспечивающая очень высокий уровень сжатия"	+/–
Сообщение от opennews (??), 30-Ноя-20, 12:26
Маркус Холланд-Мориц (Marcus Holland-Moritz) из компании Facebook опубликовал первые выпуски файловой системы DwarFS, работающей в режиме "только для чтения" и нацеленной на обеспечение максимального уровня сжатия и сокращения избыточных данных. ФС использует механизм FUSE и работает пространстве пользователя. Код написан на С++ и распространяется под лицензией GPLv3... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=54166
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

2. Сообщение от InuYasha (??), 30-Ноя-20, 12:32	–4 +/–
На ленты можно будет накатить. Хотя, там уже сами LTO-приводы, вроде, делают своё сжатие.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #52

3. Сообщение от blzz (?), 30-Ноя-20, 12:51	+1 +/–
не представляю как можно сжимать для устройства с линейным доступом, кроме как gzip/bzip2/xz или аналогов, ну в общем блок потока. ведь что-то выиграть на дедупликации внеблока нельзя, а это и есть самое выгодное для файловой системы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #4

4. Сообщение от Аноним (4), 30-Ноя-20, 13:00	–6 +/–
Вот кстати единственный архиватор, который занимается дедупликацией (помимо того что позволяет выбрать эффективные фдля контента фильтры, мог бы и сам озаботиться конечно) это zpaq. Больше никто дидуплекацию не делает — у тебя в файле будет несколько копий одних и тех же данных в итоге. Даже если файлы совершенно идентичные, архиваторы недостаточно умные, чтобы угадать идентичность по хэшам. Про потоковые и говорить нечего, конечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5, #6, #8, #25, #29, #72

5. Сообщение от Аноним (4), 30-Ноя-20, 13:02	–2 +/–
Squashfs вроде обещала дедупликацию, но я её не заметил что-то совершенно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #14

6. Сообщение от Аноним (6), 30-Ноя-20, 13:05	+4 +/–
> архиватор, который занимается дедупликацией Use Unix way, Luke. fdupes; tar Каждый при своём деле.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #7

7. Сообщение от Аноним (4), 30-Ноя-20, 13:21	–1 +/–
А если мне нужны несколько копий повторяющихся данных? Допустим, медиафайлы (и даже бинарники) одинаковые, а скрипты и переводы могут отличаться. Я конечно использую hardlink, но он просто выкидывает мета-информацию о файлах и если perl-hardlink позволял выбрать по дате или размеру какой файл оставить, то utillinux-hardlink выбирает самостоятельно и случайно? Ну, зато работает быстрее. А если файлы отличаются на пару байт (очень типичная ситуация), то он уже не дедуплицируются. По этой причине я хочу попробовать дедупликацию в btrfs для решения данной задачи, но btrfs до сих пор не поддерживает case-insensitive флаг (а значит только ext4 и вроде f2fs).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11

8. Сообщение от Anon_noXX (?), 30-Ноя-20, 14:38	–1 +/–
Не совсем, дедупликацию еще как минимум rar5 умеет, со своими тараканами, куда без этого. А так-то, если в словарь(в общем, не придираться) все вмещается, любой архиватор эффективно с дублями борется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #9

9. Сообщение от Аноним (4), 30-Ноя-20, 14:46	–2 +/–
>rar5 что-то не заметил (а ведь перебрал наверно все комбинации ключей), да и в целом в 5 раз хуже 7z жмёт. >словарь а это не выход, словарь делать больше суммарного объёма данных не вариант когда у тебя гигабайты (пусть и повторяющихся данных). У zpaq на дублирующихся данных реально в разы меньше конкурентов файл вышел.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #13

10. Сообщение от user90 (?), 30-Ноя-20, 14:46	+/–
B cразу ФС городить) С точки зрения пользователя - не интересно / "критикуешь - предлагай?" - пжалуста: ddar.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15, #17

11. Сообщение от Anon_noXX (?), 30-Ноя-20, 14:49	–1 +/–
Чьёрт подъери. "case-insensitive флаг" только ввели, а это стало киллер-фичей. На винду дуй, там это нормой является. Не нужно hardlink использовать, есть --reflink=(auto|always) опция для cp, mc умеет. Кстати, не только btrfs, ext4/xfs/что-там-еще-что-я-не-видел-никогда. "А если файлы отличаются на пару байт (очень типичная ситуация), то он уже не дедуплицируются." - это к окулисту, он до 19 работает. Если ПО не умеет в ioctl_ficlonerange/ioctl_ficlone, то дедап должен выполняться сторонними средствами, к коим и ФС относится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #12

12. Сообщение от Аноним (4), 30-Ноя-20, 14:53	+/–
>На винду дуй А что мне ещё сделать? >Не нужно hardlink использовать, есть --reflink=(auto|always) опция для cp, mc умеет Но ведь мне не нужно копировать файлы, мне нужно их удалять. Алло. >Если ПО не умеет в ioctl_ficlonerange/ioctl_ficlone Какое ещё ПО, вот у меня 2 файла с песенками, отличается только дата тагирования, всё. Дальше что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #62

13. Сообщение от Anon_noXX (?), 30-Ноя-20, 14:55	–1 +/–
Пардон, на работе только оффтопик и русский. Впрочем, читать документацию - это же не тру уних вей, да? "· Сохранять идентичные файлы как ссылки Если выбран этот параметр, то перед началом архивирования выполняется анализ содержимого файлов. Если обнаруживаются несколько идентичных файлов размером более 64 КБ, первый файл из набора сохраняется как обычный файл, а все остальные — как ссылки на этот первый файл. Это позволяет уменьшить размер архива, но накладывает некоторые ограничения на результирующий архив. Первый файл из набора идентичных файлов в созданном архиве нельзя удалять или переименовывать, потому что это сделает невозможным извлечение остальных ссылающихся на него файлов. Если изменить содержимое первого файла, то при извлечении изменёнными будут и все остальные ссылающиеся на него файлы. Команда извлечения должна применяться сначала к первому файлу, чтобы остальные файлы могли быть успешно созданы. Данный параметр рекомендуется применять только при сжатии большого количества идентичных файлов и если архив в дальнейшем не предполагается изменять, а распаковывать его вы будете полностью, без необходимости извлекать или пропускать отдельные файлы. Если все идентичные файлы достаточно малы, чтобы уместиться в словаре сжатия, то более гибкое решение, нежели данный параметр, даёт непрерывное (solid) архивирование. Поддерживается только в архивах RAR5. " Кстати, 7z вполне себе поддерживает, как думаете, что такое "solid block size"?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #19, #45

14. Сообщение от Аноним (14), 30-Ноя-20, 14:56	+2 +/–
Пофайловая есть. Одинааовые файлы сгребает еще до отправки на сжатие, можешь чекать статистику в клнце mksquashfs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #26

15. Сообщение от somebody (??), 30-Ноя-20, 14:56	–1 +/–
zfs  + compression/deduplication
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #20

16. Сообщение от Аноним (16), 30-Ноя-20, 14:56	+1 +/–
>1139 различных установок Perl, в которых встречается 284 релизов Perl а зачем столько версий? в перле совместимость часто ломают?
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (14), 30-Ноя-20, 14:59	+/–
Ссылку бы хоть оставил, а то такую имбу предложил что аж не найти
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #18

18. Сообщение от user90 (?), 30-Ноя-20, 15:03	+/–
https://github.com/basak/ddar
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

19. Сообщение от Аноним (4), 30-Ноя-20, 15:04	+/–
Почему ты такой теоретик? Давай сделай запрошенное, потом приходи и рассказывай, как кто-то там не умеет читать справку, угумс? Только убедись хорошенько, что заявленная "дедупликация" работает, хотя бы со словарём ну там допустим 256мб и датасетом в несколько гигабайт с дублированными данными где-то на гигабайт-полтора. Я вот знаю результат заранее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #21

20. Сообщение от user90 (?), 30-Ноя-20, 15:07	–2 +/–
Ога, побежал разделы переформатировать)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

21. Сообщение от Anon_noXX (?), 30-Ноя-20, 15:12	+/–
Ок, "ты", значит ты. Я - практик, на нужных мне датасетах rar не использую, он хуже 7z lzma2 жмет. Впрочем, обхожусь gzip -3, местами -9, сжатие 20-25 кратное меня устраивает, да и процов не напасешься на моих датасетах. Расскажи, что у тебя и сколько компрессии подвергается. Я вот xml жму, в основном, 15-20 ТБ/сутки(впрочем, считал 2-3 года назад, сейчас сильно больше), с интересной латентностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #23, #32

22. Сообщение от Аноним (-), 30-Ноя-20, 15:30	+7 +/–
>Код написан на С++ и распространяется под лицензией GPLv3. Маркус правильный пацан.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #68, #74

23. Сообщение от Аноним (4), 30-Ноя-20, 15:31	–1 +/–
Ни к чему выпендрёж. У меня было аж несколько различных кейсов, где размер файла имел значение — это архивирование в облако и передача по сети, и я под это заморочился выяснить как можно сжать поэффективнее. Типичная задача для меня это пожать несколько билдов для разных платформ сумарным объёмом в пределах 5-15гб, и файлы там повторяются. Когда же билдов несколько версий, количество дубликатов соответственно увеличивается весьма значительно. О чём я и говорю, архиваторы не справляются. Был ещё кейс где сколько-то терабайт текстовых данных (ну т.е. жмутся очень хорошо, ага) и дубликаты там тоже были значительным процентом. Тут понятно что только потоковое сжатие возможно, но дедупликация тоже. П.с. gzip слишком медленный и неудобный, лучше уж zstd (собственно, это предпочтительный формат, особенно когда данные придётся извлекать больше 1 раза) -- ещё бы дедуплицированный тар ему скармливать и было бы вообще прекрасно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #24, #64

24. Сообщение от Аноним (4), 30-Ноя-20, 15:35	–1 +/–
Вообще, это забавно, когда сильно сжатые данные занимают места больше чем почти бесплатно дедуплицированные без сжатия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #60

25. Сообщение от anonymous (??), 30-Ноя-20, 15:45	+/–
exdupe еще есть (http://www.quicklz.com/exdupe/), заявляется как самый быстрый дедупликатор, но это экзотика, разработка встала. То ли вылизали идеально, то ли заброшен проект...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #38

26. Сообщение от Аноним (4), 30-Ноя-20, 16:02	–2 +/–
Не знаю, я сжимал 2 копии одинаковых файлов лежащих рядом (они не рядом с точки зрения архиватора, файлов было много) и ни архиваторы ни squash и приблизиться не смогли к zpaq (по времени у того сравнимо с 7z, примерно одинаково даже).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #27, #39, #49

27. Сообщение от Аноним (4), 30-Ноя-20, 16:03	–3 +/–
7z кстати при этом сжал почему-то лучше squashfs (там xz компрессором был).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

28. Сообщение от Онанимус (?), 30-Ноя-20, 16:09	+7 +/–
> В этом году автор нашёл время для доведению кода до публичного релиза и написание документации. Что ковид животворящий делает!!! Вот не было бы локдауна - так мир бы и не узнал.
Ответить | Правка | Наверх | Cообщить модератору

29. Сообщение от Аноним (32), 30-Ноя-20, 16:21	–2 +/–
winrar умеет в дедупликацию одинаковых файлов, нужные опции можно в мане посмотреть)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #31

30. Сообщение от Аноним (30), 30-Ноя-20, 16:24	–1 +/–
Perl - двигатель прогресса.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #59

31. Сообщение от Аноним (4), 30-Ноя-20, 16:27	+/–
> winrar умеет в дедупликацию одинаковых файлов, нужные опции можно в мане посмотреть) Это проприетарная программа, возможно в бесплатной версии это не работает. Или в линуксовой версии это не работает. Или баг.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #33

32. Сообщение от Аноним (32), 30-Ноя-20, 16:29	+/–
твой gzip жутко медленный и однопоточный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #61

33. Сообщение от Аноним (32), 30-Ноя-20, 16:31	–1 +/–
меня єто не останавливает!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

34. Сообщение от Аноним (34), 30-Ноя-20, 16:41	–1 +/–
В полку ФС пополнение... капец(((
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #40

35. Сообщение от Аноним (34), 30-Ноя-20, 16:43	+2 +/–
Какая по счету и индексу ненужности фс?
Ответить | Правка | Наверх | Cообщить модератору

36. Сообщение от Аноним (36), 30-Ноя-20, 16:56	+/–
Сколько шакалов из 10?
Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от Аноним (37), 30-Ноя-20, 17:08	+3 +/–
Нигде и никогда еще в мире не собиралось столько специалистов по дедупликации в одном месте.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41

38. Сообщение от Аноним84701 (ok), 30-Ноя-20, 17:10	+/–
> exdupe еще есть (http://www.quicklz.com/exdupe/), заявляется как самый быстрый дедупликатор, > но это экзотика, разработка встала. То ли вылизали идеально, то ли заброшен проект... Если из "заброшенного" (но вполне рабочего), то тогда уж zbackup, дает хорошую дедупликацию, неплохо конфигурируется (размер окна, сжатие),  можно монтировать как ФС на чтение, можно отключить встроенное сжатие и сжимать результат. И лицензия более подходящая для форка, а не мутные "restricted and non-permissive terms". Есть еще rdedup (на том самом ЯП, который-нельзя-называть, начинается на r, кончается на ust). По эффективности пожалуй лучше zbackup будет (тыкал где-то год назад, но у меня все упирается в IO) и на мой вкус слишком комбайнист -- встроили шифрование, поддержку облаков и прочее. Впрочем, zbackup этим (шифрование) тоже грешит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

39. Сообщение от Аноним (39), 30-Ноя-20, 17:19	+/–
Можно перед mksquashfs прогнать любой дедупликатор, заменяющий копии на симлинки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #46

40. Сообщение от Аноним (40), 30-Ноя-20, 17:23	+1 +/–
Да не плачь, нормально всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

41. Сообщение от Аноним (41), 30-Ноя-20, 17:28	+3 +/–
И все они одиннаковые. Надо бы их дедублицировать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #65

42. Сообщение от Аноним (42), 30-Ноя-20, 17:35	–2 +/–
название он выбрал не самое удачное. В гугле фиг найдёшь по не хоть что-то, всё дварфы попадаются и игры с ними...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #43

43. Сообщение от rvs2016 (ok), 30-Ноя-20, 18:17	+/–
> название он выбрал не самое удачное. В гугле фиг найдёшь по не хоть что-то Ну после такого бурного обсуждения на Опеннете теперь можно будет нагуглить уже не фиг, полтора фига!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

44. Сообщение от Аноним (44), 30-Ноя-20, 18:30	–1 +/–
Ну норм так, можно торренты сжимать сидировать например.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #54

45. Сообщение от phrippy (ok), 30-Ноя-20, 19:14	+/–
> Если изменить содержимое первого файла, то при извлечении изменёнными будут и все остальные ссылающиеся на него файлы. Что за мамкин программист прорабатывал эту логику? CoW - не, не слышал?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #47

46. Сообщение от Аноним (46), 30-Ноя-20, 19:21	+/–
Зачем, если и так есть файловая дедубликация? Блочной нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

47. Сообщение от RM (ok), 30-Ноя-20, 19:52	+/–
Это как symlink логика
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

48. Сообщение от Аноним (48), 30-Ноя-20, 20:49	–5 +/–
> использует механизм FUSE и работает в пространстве пользователя > повышение эффективности использования процессорного кэша > очень высокий уровень сжатия > LZ4 Ненужнометр перешёл красную отметку и напоминающе звенит.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #51

49. Сообщение от Led (ok), 30-Ноя-20, 21:20	+2 +/–
>архиваторы При чём тут архиваторы? Архиваторы архивирут, а не сжимают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #50

50. Сообщение от Аноним (4), 30-Ноя-20, 21:22	–4 +/–
Так и мне нужна ДЕДУПЛЕКАЦИЯ, а не СЖАТИЕ. Это задача АРХИВАТОРА, а не КОМПРЕССОРА.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #63

51. Сообщение от Led (ok), 30-Ноя-20, 21:27	+3 +/–
Про LZ4HC что-то слышал, ламерок?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #53, #76

52. Сообщение от Прокоповна (?), 30-Ноя-20, 21:58	–1 +/–
Вечера дедупликации на опеннет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

53. Сообщение от Прокоповна (?), 30-Ноя-20, 22:04	–4 +/–
>  ламерок? Нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

54. Сообщение от Аноним (54), 30-Ноя-20, 22:31	+/–
Уже давно есть всепланетная файловая ситсема, так что не нужен уже торрент.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

55. Сообщение от Аноним (-), 01-Дек-20, 01:01	+/–
Это поможет портировать OpenWrt на старые роутеры?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56

56. Сообщение от Дмитрий Ю.Карпов (?), 01-Дек-20, 02:13	+/–
Зависит от того, где OpenWrt хранит изменяемые настройки. Хотя можно сделать сжатую файловую систему для базовых файлов; и поверх неё смонтировать UnionFS для изменяемых файлов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #70

57. Сообщение от Аноним (57), 01-Дек-20, 04:34	+/–
а "кластеризация похожих данных" не будет усложнять запаковку больших объемов данных в геометрической зависимости от их размера?
Ответить | Правка | Наверх | Cообщить модератору

58. Сообщение от Аноним (-), 01-Дек-20, 06:37	+/–
> обеспечивающая очень высокий уровень сжатия πfs всё равно лучше.
Ответить | Правка | Наверх | Cообщить модератору

59. Сообщение от Lex (??), 01-Дек-20, 06:49	+1 +/–
*смерть перла - двигатель прогресса
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

60. Сообщение от Anon_noXX (?), 01-Дек-20, 07:20	+/–
Сложно возразить. Я же не отрицаю полезность дедупликации :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

61. Сообщение от Anon_noXX (?), 01-Дек-20, 07:23	+/–
Льстец, gzip не мой :) Я умею треды использовать, однопоточность gzip тут только в плюс.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

62. Сообщение от Anon_noXX (?), 01-Дек-20, 07:43	+/–
"мне нужно их удалять" - вот и удаляй. "отличается только дата тагирования, всё. Дальше что?" - ой, всё! :) Дуй на винду и храни тэги в ntfs потоках, блочные фс не умеют разницу в пару байт обрабатывать. А ты, кстати, в курсе, что винда умеет в транзакции для ntfs? Просто вопрос.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

63. Сообщение от vitektm (?), 01-Дек-20, 09:03	+/–
exdupe  и сжимает и дедуплицирует и с космической скоростью. Есть правда минус чтобы сильно сжать нужно  много оперативы. Но скажем сжать пару ТБ  архивов msSQL сможет на ура. (в до 10-20 раз может ужать) Есть дифы. Давное не обновлялся. И есть аналоги может даже где-то лучше. (скорее всего уже точно есть в чем-то лучше)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

64. Сообщение от Anon_noXX (?), 01-Дек-20, 09:09	+/–
Прям уж выпендреж, не хотел, пардон, если так получилось. Да, 5-15ГБ - это же образы для ВМ, надеюсь, правильно понял? Для этих случаев имеются отдельные решения, не связаные с дедубликацией и сжатием, хотя и то и другое, несомненно, имеют право на существование. Это, скорее, проблема блочных ФС.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

65. Сообщение от Аноним (65), 01-Дек-20, 10:03	+/–
да вы батенька технофашист.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

66. Сообщение от Аноним (66), 01-Дек-20, 14:53	+/–
Я тут не давно только для себя открыл SquashFS - очень хорошо подходит для всяких скриптов кторых очень уж много в одной папка(директории). Директория  node_modules в 600Мб - запаковалась в 32 Мб, и если пакеты не меняются то очень удобно ее монтировать , а тут бац и еще одна ФС появилась.....
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #69, #71

67. Сообщение от Дерьмократ (?), 01-Дек-20, 18:26	+/–
Написать код без кучи зависимостей от фэйсбучных либ он, конечно, не смог.
Ответить | Правка | Наверх | Cообщить модератору

68. Сообщение от Дерьмократ (?), 01-Дек-20, 18:28	+/–
Просто фейсбук жадный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

69. Сообщение от Аноним (4), 01-Дек-20, 20:00	+/–
Она очень медленная и жрёт процессор, лагает. Я наоборот пришёл к тому, что все использующиеся данные должны быть несжатыми. Это экономит и время и процессор например на ссд, на нжмд чтение могло быть заметно медленным и там это ещё оправдано -- чем меньше файлы, тем лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #75

70. Сообщение от Рева RarogCmex Денис (?), 01-Дек-20, 21:29	+/–
Overlayfs же.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

71. Сообщение от Рева RarogCmex Денис (?), 01-Дек-20, 21:31	+/–
Можешь попробовать fuse-overlayfs для того, чтобы спокойно менять при необходимости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

72. Сообщение от Аноним (4), 02-Дек-20, 22:55	+/–
Да, 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
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #73

73. Сообщение от Аноним (4), 02-Дек-20, 23:20	+/–
7z (2016 года правда) со словарём в половину объёма данных (как раз влезет целиком после дедуплекации) и ms=on кстати победил, и я так понимаю все данные были эффективно дедуплицированы и сжаты (ценой памяти и времени), но это работает только там где файлы крошечные. Ну т.е. реалистично в пределах гигабайта может быть, больше словарь делать будет проблематично. При словаре 512mb файл получился на 1 килобайт меньше чем со словарём 256mb. Чтобы это проверить, пожал также со словарём в 4 раза меньше чистых данных (64mb) и архив получился больше в 4 раза, одинаково с tar-xz. Т.е. моя изначальная версия по поводу размера словаря и эффективности работы верна: там где нет возможности поместить все данные в окно словаря в памяти, zpaq выходит на первое место по качеству и эффективности сжатия, в остальных случаях лидирует 7z. Можно конечно и xz попробовать с нестандартным словарём, наверное тоже будет работать (если он может словарь больше 64).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

74. Сообщение от Аноним (-), 03-Дек-20, 12:59	+/–
Да какой же правильный? С C++ и фузом он будет тормозной и squashfs при всем желании не заменит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

75. Сообщение от Аноним (76), 03-Дек-20, 13:02	+1 +/–
Так жмите LZO каким или LZ4, тогда может даже ускориться - за счет того что читать меньше. Они распаковываются со скоростью сотни мегов а то и гигабайты в секунду, и при том скрипты неплохо сожмут, раза в 2-3 запросто. На SSD это оправдано экономией места, которое стоит денег, при том не особо мало, особенно на хорошем SSD а на бросовой сыпучке TLC.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

76. Сообщение от Аноним (76), 03-Дек-20, 13:04	–1 +/–
> Про LZ4HC что-то слышал, ламерок? еще lz4ultra вспомните, блин... а таки сколько LZ4 не жми, LZMA он не станет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

77. Сообщение от bOOster (ok), 08-Дек-20, 09:57	+/–
Скорость формирования образа тут зачем?? Скорость и уровень сжатия всегда идут в компромиссе. И в решении 1 раз сжал - миллион раз используй - как бы вообще скорость смысла не имеет.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #78

78. Сообщение от Аноним (78), 08-Дек-20, 19:14	+/–
Это вы просто не видели компрессоров которые пакуют 100 килобайтов порядка часа на core i7.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

79. Сообщение от Аноним (79), 11-Июн-23, 18:57	+/–
Особенно приятно что багов немного и они оперативно закрываются https://github.com/mhx/dwarfs/issues
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема