>на уровне блоков естественным образом укладывается в 256-битную контрольную сумму блоков ZFS,
а какой там размер блока?
просто меня смущает, что 512kB -> via SHA -> 256 bit, то не только у одинаковых блоков будет одинаковая сигнатура
Подозреваю, что на разделе с коллективной файлопомойкой, почтой, VM или каким-нибудь хостингом циферки будут несколько иными. Но проверить, к сожалению, мне негде. А в рядовом /home дупликатам и неоткуда взяться.
> А теперь расскажите нам, что делают фанатики Ъ-линукс-way тогда, когда каждую виртуальную машину придется обновить?
Только после того, как вы расскажите нам, как отреагирует система в виртуальной машине, если во время перезаписи данных (с точки зрения гостевой ОС), вдруг прилетит сообщение "Out of disk space", и как в процессе неудачного отката транзакции нафиг рассыпется ФС этой гостевой машины, а также всех остальных :-)
>Не, надо считать, сколько займет чтения 1ГБ-файла с _диска_ в сравнении с распаковкой 100МБ, например.
Современные жесткие диски обладают скоростью линейного чтения порядка 80-100 Мб/с. Итого гигабайт будет читаться порядка 15 секунд. 6.5 Мб gzip'нутый архив распаковывался 0.22 секунды, значит, грубо говоря, 100-мегабайтный архив распакуется за 3.4 секунды. Правда, тут есть одно "но": такой 100-мегабайтный архив соответствует 338 мегабайтам несжатых данных (ты нули чтоли собрался паковать с таким высоким коэффициентом сжатия -- 1Gb -> 100Mb?).
Ну и мой любимый вопрос: как быть с перемещением по фрагментам сжатого файла? Либо ты будешь жать отдельные блоки с получением значительного проигрыша по степени сжатия, либо ты жмешь весь файл целиком и операция lseek будет ну ооочень небыстрой.
И вдогонку насчет хостингов - на них повторяются всякие PHPbb и прочие, но при более-менее большом размере блока (хотя-бы 64КБ) дублирующихся блоков будет очень мало (файлы пишутся в разном порядке).
Как и следовало ожидать, два блока с количеством ссылок равным 1, блоки по 128К, соответственно на диске занимают 256К. Скопируем тот же файлик в сжатую ФС:
Что мы видим? Блоков стало 4, но добавленные два на диске занимают меньше места за счет сжатия. Количество ссылок по-прежнему 1, колонки allocated и referenced не отличаются. Теперь добавим рядом тот же файл еще раз:
Становится интереснее - появилась строчка с количеством ссылок 2; места на диске было бы выделено столько же, а файлов в полтора раза больше. Добавим рядом тот же файл в сжатой ФС:
Если "место" уже зарезервировано, то дедупликация не нужна. ЧиТД.
> откуда прилетит сообшение?
Раздел с дедупликацией, на занятый на 90% четырьмя образами BlueRay-дисков. Клиент начинает переписывать один образ другими данными. В момент когда от нового диска запишется 50%, прилетит Out of Disk Space.
> Только после того, как вы расскажите нам, как отреагирует система в виртуальной машине, если во время перезаписи данных (с точки зрения гостевой ОС), вдруг прилетит сообщение "Out of disk space", и как в процессе неудачного отката транзакции нафиг рассыпется ФС этой гостевой машины, а также всех остальных :-)
Вам придется рассказать раньше, так как при прочих равных в системе без дедупликации сообщение "out of space" прилетит гораздо раньше :-)
> так как при прочих равных в системе без дедупликации сообщение "out of space" прилетит гораздо раньше
В промышленной эксплуатации отведение места под VM производится на этапе создания VM. Что приводит к тому, что либо VM гарантированно работает, либо не создается.
> Раздел с дедупликацией, на занятый на 90% четырьмя образами BlueRay-дисков. Клиент начинает переписывать один образ другими данными. В момент когда от нового диска запишется 50%, прилетит Out of Disk Space.
Заставь дурака богу молиться - он и лоб расшибет. Кто ж в зравом уме будет включать дедупликацию для ФС с уникальными данными? Это раз.
Два, если четыре образа разные - то ничего такого не произойдет, он спокойно себе перезапишется.
А заодно расскажите нам, что происходит со снимками LVM, когда кончается место, для них щарезервированное. Подозреваю, эффекты не менее феерические. Или снапшоты LVM изнутри в X раз больше, чем снаружи (где X - любое положительное число большее 1)?
> В промышленной эксплуатации отведение места под VM производится на этапе создания VM. Что приводит к тому, что либо VM гарантированно работает, либо не создается.
Угу, только даже если они были созданы путем клонирования, после первого же обновления первоначальный экономический эффект начнет сходить на нет, а после нескольких обновлений они и вообще могут распухнуть так, что его трудно будет измерить.
А вот у меня например щас большой зоопарк с торрентами, который раздаю и самими файлами, которые использую.
Качаешь 3 торрента, потом делаешь сим-линки на файлы первого, потом перекрываешь их симлинками на файлы второго, а потом уже симлинками на файлы третьего. И еще запрещаешь изменять их (что не есть хорошо всегда)
>>Вот только этот прекрасный день при прочих равных наступит несколько позже в случае с дедупликацией и несколько раньше в случае без нее
>Без этого я точно знаю сколько у меня занимают образы, их размер внезапно не изменится.
Речь не идет про изменение размера образа, речь идет об изменении его содержимого. И если они были созданы путем клонирования одного снимка, то в результате применения однотипных изменений к каждому без дедупликации размер занимаемого пространства на диске будет расти, а с дедупликацией - нет, ну или если и будет, то гораздо медленнее.
И вы, например, сможете уместиться в систему хранения среднего уровня вместо какой-нибудь топовой железки.
Нет, вы, конечно, безусловно можете быть потомком Рокфеллера, и позволять себе разбрасываться местом направо и налево :-) но вот почему то так сложилось, что дедупликация - востребованная тема у тех, кто серьезно занимается виртуализацией.
Вы и с дедупликацией и без дедупликации будете знать точно, сколько места занято, сколько свободно. Если вы, конечно, будете себя тешить иллюзиями, что у вас свободно не столько, сколько физически свободно, а сколько свободно физически на коэффициент эффективности дедупликации, то да, вы можете столкнуться с неприятными сюрпризами. Но это будет результат ваших иллюзий, ни больше, ни меньше.
Сто гигов? Счас в ноутбуках уже винты в три-пять раз больше :-)
Да-да я сейчас для тебя пойду корпоративный сторадж лопатить.
Давай свою статистику. Зачем эти странные теории и примеры с клонами вирт. машин и торентами? Это все-равно что делать бэкап оракла средствами ФС, а не его собственным утилем.
Как бы намекают: сжатие больше не нужно. Незачем тратить ресурсы CPU на сжатие - лучше/быстрее будет работать дедупликация. Ещё инкрементные бэкапы сами собой будут образовываться простым копированием, без использования спец.утилит.
Дедупликация и так учитывает уникальные блоки данных и не увеличивает количество дубликатов, а наоборот — меньшает их (как бы логично из названия механизма). Улучшается скорость ввода-вывода, так как при операциях с одинаковыми файлами из носителя в память загружается только один блок данных (например, лицензионное соглашение в куче текстовых файлов будет одно, и часть блоков данных, содержащих его, одинаковы). Алгоритмы компрессии не задействуются — меньше расход ресурсов CPU.
Блоки данных нельзя сжать по отдельности, поэтому в ФС сжимаются файлы, состоящие из этих блоков. Алгоритм сжатия слишком интеллектуальный, чтобы не учитывать уникальность блоков, а жать весь файл наиболее оптимальным образом. Например, два текстовых файла, отличающихся несколькими байтами, будут ужаты и иметь абсолютно все отличающиеся блоки данных. ВСЕ блоки данных — что в случае дедупликации быть не могло в принципе. Для систем контроля версий сжатие на лету будет накладно как по объёму занимаемого места, так и по времени доступа. Так что для /usr/src дедупликация — самое то, если нужен быстрый доступ к исходникам и их модификация.
Разреженные файлы. Естественно, такие вещи имеют много одинаковых блоков сами по себе и ужимаются очень хорошо. Так что дедупликация здесь работает как простое RLE-«сжатие» данных, а сжатие на лету алгоритмом GZIP может ещё больше уменьшить занимаемое файлом место.
Обычные бинарные файлы, файлы архивов и мультимедиа файлы — здесь оптимизируются только заголовки (и то не все). Дедупликация и сжатие вообще не помогут НИКАК.
Обычные бинарные файлы, файлы архивов и мультимедиа файлы... Дедупликация и сжатие вообще не помогут НИКАК.
Первая умная мысль. Это именно то что я хотел показать своим скриптом — в обычных не связанных между собой файлах фактически нет одинаковых блоков.
Т.е. дедупликация может быть эффективной на фс с особым содержимым.
Вопрос что это за содержимое такое, чтобы получить профит от дедупликации?
Лицензии в текстовых файлах — это лажа, не стоящая ничего.
Я могу предложить вариант хранения лицензии в отдельном файле и автоматическое вклеивание его в начало каждого файла при экспорте проекта из VCS. Это кстати избавляет кодера от необходимости вставлять лицензию в каждый файл и в случае изменения лицензии менять придется только в одном файле.
Системы контроля версий хранят дифы, а не предыд. версии файлов.
Бинарные документы (типа pdf, doc, odt), даже отличаясь в тексте на одну букву, в бинарном виде будут сильно различаться.
Разреженные файлы, на то и разреженные, что не занимают блоков на диске (имеют дыры), т.е. тут вообще нечего дедуплицировать.
Клонирование вирт. машин — производится средствами самих вирт. машин.
Что еще?
З.Ы. Я не пытаюсь намерено дискредитировать идею автоматической дедупликации, а хочу найти ей область применения с максимальным эффектом (с экономией > 10% места хотя бы)