ZFS не нужна

> В один прекрасный и непредсказуемый день место на разделе кончается, виртуальная машина в непонятках, где ее 8ГБ.

Вот только этот прекрасный день при прочих равных наступит несколько позже в случае с дедупликацией и несколько раньше в случае без нее

Не, надо считать, сколько займет чтения 1ГБ-файла с _диска_ в сравнении с распаковкой 100МБ, например.

>Вот только этот прекрасный день при прочих равных наступит несколько позже в случае с дедупликацией и несколько раньше в случае без нее

Без этого я точно знаю сколько у меня занимают образы, их размер внезапно не изменится.

>на уровне блоков естественным образом укладывается в 256-битную контрольную сумму блоков ZFS,
а какой там размер блока?
просто меня смущает, что 512kB -> via SHA -> 256 bit, то не только у одинаковых блоков будет одинаковая сигнатура

Подозреваю, что на разделе с коллективной файлопомойкой, почтой, VM или каким-нибудь хостингом циферки будут несколько иными. Но проверить, к сожалению, мне негде. А в рядовом /home дупликатам и неоткуда взяться.

> А теперь расскажите нам, что делают фанатики Ъ-линукс-way тогда, когда каждую виртуальную машину придется обновить?

Только после того, как вы расскажите нам, как отреагирует система в виртуальной машине, если во время перезаписи данных (с точки зрения гостевой ОС), вдруг прилетит сообщение "Out of disk space", и как в процессе неудачного отката транзакции нафиг рассыпется ФС этой гостевой машины, а также всех остальных :-)

> просто меня смущает, что 512kB -> via SHA -> 256 bit

В примерах в статье по ссылке приводится опция verify :-)

>не только у одинаковых блоков будет одинаковая сигнатура

Внедрение ZFS dedup в большом ЦОД станет отличным способом наконец-то найти коллизии в SHA.

:3

> на разделе [...] каким-нибудь хостингом циферки будут несколько иными

"На разделе с каким-нибудь хостингом" это называется overselling, и за это в приличных местах бьют по рукам :-)

Место под диски VM ведь уже зарезервировано, откуда прилетит сообшение?

Да и вообще, держать данные внутри VM – моветон каких поискать, для этого системы хранения есть.

>Не, надо считать, сколько займет чтения 1ГБ-файла с _диска_ в сравнении с распаковкой 100МБ, например.

Современные жесткие диски обладают скоростью линейного чтения порядка 80-100 Мб/с. Итого гигабайт будет читаться порядка 15 секунд. 6.5 Мб gzip'нутый архив распаковывался 0.22 секунды, значит, грубо говоря, 100-мегабайтный архив распакуется за 3.4 секунды. Правда, тут есть одно "но": такой 100-мегабайтный архив соответствует 338 мегабайтам несжатых данных (ты нули чтоли собрался паковать с таким высоким коэффициентом сжатия -- 1Gb -> 100Mb?).

Ну и мой любимый вопрос: как быть с перемещением по фрагментам сжатого файла? Либо ты будешь жать отдельные блоки с получением значительного проигрыша по степени сжатия, либо ты жмешь весь файл целиком и операция lseek будет ну ооочень небыстрой.

И вдогонку насчет хостингов - на них повторяются всякие PHPbb и прочие, но при более-менее большом размере блока (хотя-бы 64КБ) дублирующихся блоков будет очень мало (файлы пишутся в разном порядке).

Ну мы же технику обсуждаем, какое нам дело до какой-то там морали и прочих общечеловеческих. :3

как я пониаю, еще в отличает от LVM zfs позволяет все это делать в пределах пула, а не одной ФС

Я это писал про скрипт sdio, которым он оценил 3.5% и который обсчитывает блоки файлов.

Не все так просто. Насколько я понял идею сантехников, это считается двумя разными файлами

Не считается, а так и есть - файлы остаются разными. В случае hard-линков - это будет один файл с разными именами.

Вобщем, вот пример:

bash-3.2# mkfile -n 64m /var/tmp/dedup
bash-3.2# zpool create dedup /var/tmp/dedup
bash-3.2# zfs create -o compression=on dedup/compressed
bash-3.2# cp /usr/dict/words /dedup/words1
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1        2    256K    256K    256K        2    256K    256K    256K
 Total        2    256K    256K    256K        2    256K    256K    256K

dedup = 1.00, compress = 1.00, copies = 1.00, dedup * compress / copies = 1.00

Как и следовало ожидать, два блока с количеством ссылок равным 1, блоки по 128К, соответственно на диске занимают 256К. Скопируем тот же файлик в сжатую ФС:

bash-3.2# cp /usr/dict/words /dedup/compressed/words1
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1        4    512K    395K    395K        4    512K    395K    395K
 Total        4    512K    395K    395K        4    512K    395K    395K

dedup = 1.00, compress = 1.30, copies = 1.00, dedup * compress / copies = 1.30

Что мы видим? Блоков стало 4, но добавленные два на диске занимают меньше места за счет сжатия. Количество ссылок по-прежнему 1, колонки allocated и referenced не отличаются. Теперь добавим рядом тот же файл еще раз:

bash-3.2# cp /usr/dict/words /dedup/words2
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1        2    256K    139K    139K        2    256K    139K    139K
     2        2    256K    256K    256K        4    512K    512K    512K
 Total        4    512K    395K    395K        6    768K    651K    651K

dedup = 1.65, compress = 1.18, copies = 1.00, dedup * compress / copies = 1.94

Становится интереснее - появилась строчка с количеством ссылок 2; места на диске было бы выделено столько же, а файлов в полтора раза больше. Добавим рядом тот же файл в сжатой ФС:

bash-3.2# cp /usr/dict/words /dedup/compressed/words2
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     2        4    512K    395K    395K        8      1M    790K    790K
 Total        4    512K    395K    395K        8      1M    790K    790K

dedup = 2.00, compress = 1.30, copies = 1.00, dedup * compress / copies = 2.59

Блоков с количеством ссылок 1 не осталось бы, а места по-прежнему было бы выделено столько же :-)

Теперь интереснее - сделаем снимок и склонируем обе ФС:

bash-3.2# zfs snapshot -r dedup@now
bash-3.2# zfs clone dedup@now dedup/clone
bash-3.2# zfs clone dedup/compressed@now dedup/clone/compressed
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     2        4    512K    395K    395K        8      1M    790K    790K
 Total        4    512K    395K    395K        8      1M    790K    790K

dedup = 2.00, compress = 1.30, copies = 1.00, dedup * compress / copies = 2.59

Ничего не изменилось бы, как и ожижалось. А теперь перезапишем файлы в склонированных ФС:

bash-3.2# cp /usr/dict/words /dedup/clone/words1
bash-3.2# cp /usr/dict/words /dedup/clone/compressed/words1
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     2        4    512K    395K    395K       10   1.25M   1.02M   1.02M
 Total        4    512K    395K    395K       10   1.25M   1.02M   1.02M

dedup = 2.65, compress = 1.22, copies = 1.00, dedup * compress / copies = 3.24

А на диске по-прежнему было бы использовано столько же места! Теперь перезапишем вторые файлы:

bash-3.2# cp /usr/dict/words /dedup/clone/words2
bash-3.2# cp /usr/dict/words /dedup/clone/compressed/words2
bash-3.2# zdb -S dedup
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     2        2    256K    139K    139K        4    512K    278K    278K
     4        2    256K    256K    256K       12   1.50M   1.50M   1.50M
 Total        4    512K    395K    395K       16      2M   1.77M   1.77M

dedup = 4.59, compress = 1.13, copies = 1.00, dedup * compress / copies = 5.18

Количество использованного на диске места осталось бы неизменным :-)

На самом деле этот пул пока что без дедупликации, и zfs list для его ФС говорит следующее:

bash-3.2# zfs list -r dedup NAME USED AVAIL REFER MOUNTPOINT dedup 2.00M 25.5M 538K /dedup dedup/clone 1.04M 25.5M 537K /dedup/clone dedup/clone/compressed 532K 25.5M 536K /dedup/clone/compressed dedup/compressed 302K 25.5M 302K /dedup/compressed

Что соответствует колонке referenced из последнего вывода. То есть вместо 2М могло бы быть занято чуть меньше, чем 400К.

Вот такая вот экономия.

> Место под диски VM ведь уже зарезервировано

Если "место" уже зарезервировано, то дедупликация не нужна. ЧиТД.

> откуда прилетит сообшение?

Раздел с дедупликацией, на занятый на 90% четырьмя образами BlueRay-дисков. Клиент начинает переписывать один образ другими данными. В момент когда от нового диска запишется 50%, прилетит Out of Disk Space.

> Только после того, как вы расскажите нам, как отреагирует система в виртуальной машине, если во время перезаписи данных (с точки зрения гостевой ОС), вдруг прилетит сообщение "Out of disk space", и как в процессе неудачного отката транзакции нафиг рассыпется ФС этой гостевой машины, а также всех остальных :-)

Вам придется рассказать раньше, так как при прочих равных в системе без дедупликации сообщение "out of space" прилетит гораздо раньше :-)

Вообще вот он профит от более современой архитектуры в отличае от старых методов

когда подсистемы обладают большим знанием друг о друге, разработывать их сложнее, но работать они могу эффективней

> В момент когда от нового диска запишется 50%, прилетит Out of Disk Space.

Резервируй всегда кусок свободного места

Используй квоты так, чтоб они не дали возможность прийти в такие ситуации

> Вобщем, вот пример

Это не пример, это мастурбация :-)

> так как при прочих равных в системе без дедупликации сообщение "out of space" прилетит гораздо раньше

В промышленной эксплуатации отведение места под VM производится на этапе создания VM. Что приводит к тому, что либо VM гарантированно работает, либо не создается.

> Раздел с дедупликацией, на занятый на 90% четырьмя образами BlueRay-дисков. Клиент начинает переписывать один образ другими данными. В момент когда от нового диска запишется 50%, прилетит Out of Disk Space.

Заставь дурака богу молиться - он и лоб расшибет. Кто ж в зравом уме будет включать дедупликацию для ФС с уникальными данными? Это раз.

Два, если четыре образа разные - то ничего такого не произойдет, он спокойно себе перезапишется.

А заодно расскажите нам, что происходит со снимками LVM, когда кончается место, для них щарезервированное. Подозреваю, эффекты не менее феерические. Или снапшоты LVM изнутри в X раз больше, чем снаружи (где X - любое положительное число большее 1)?

Дрочерство/недорочерство. А zfs под мак надо срочно форкать

> > Вобщем, вот пример

> Это не пример, это мастурбация :-)

Что, нечем крыть? :-)

> В промышленной эксплуатации отведение места под VM производится на этапе создания VM. Что приводит к тому, что либо VM гарантированно работает, либо не создается.

Угу, только даже если они были созданы путем клонирования, после первого же обновления первоначальный экономический эффект начнет сходить на нет, а после нескольких обновлений они и вообще могут распухнуть так, что его трудно будет измерить.

Или и тут спорить будете?

> это сказки, как и буки с рейдами

Что не мешает их продавать: http://price.ru/bin/price/prodlist?pnam=raid&incid=1&tid=&acod=&a... :)

Когда предоставишь статистику по реальной файлопомойке, тогда и говори.

Я еще прогнал по 100Г системе с файлами ОС, вирт. машинами, разной документацией, фотками, медиаконтентом, ...

Получилось еще меньше — 1.6%

А вот у меня например щас большой зоопарк с торрентами, который раздаю и самими файлами, которые использую.

Качаешь 3 торрента, потом делаешь сим-линки на файлы первого, потом перекрываешь их симлинками на файлы второго, а потом уже симлинками на файлы третьего. И еще запрещаешь изменять их (что не есть хорошо всегда)

А так было бы хорошо: скопировал и пользуешься

>>Вот только этот прекрасный день при прочих равных наступит несколько позже в случае с дедупликацией и несколько раньше в случае без нее

>Без этого я точно знаю сколько у меня занимают образы, их размер внезапно не изменится.

Речь не идет про изменение размера образа, речь идет об изменении его содержимого. И если они были созданы путем клонирования одного снимка, то в результате применения однотипных изменений к каждому без дедупликации размер занимаемого пространства на диске будет расти, а с дедупликацией - нет, ну или если и будет, то гораздо медленнее.

И вы, например, сможете уместиться в систему хранения среднего уровня вместо какой-нибудь топовой железки.

Нет, вы, конечно, безусловно можете быть потомком Рокфеллера, и позволять себе разбрасываться местом направо и налево :-) но вот почему то так сложилось, что дедупликация - востребованная тема у тех, кто серьезно занимается виртуализацией.

Вы и с дедупликацией и без дедупликации будете знать точно, сколько места занято, сколько свободно. Если вы, конечно, будете себя тешить иллюзиями, что у вас свободно не столько, сколько физически свободно, а сколько свободно физически на коэффициент эффективности дедупликации, то да, вы можете столкнуться с неприятными сюрпризами. Но это будет результат ваших иллюзий, ни больше, ни меньше.

> Я еще прогнал по 100Г системе с файлами ОС, вирт. машинами, разной документацией, фотками, медиаконтентом, ...

Сто гигов? Счас в ноутбуках уже винты в три-пять раз больше :-)

> Получилось еще меньше -- 1.6%

Это говорит только лишь о том, что вам для вашей файловой системы на текущий момент это не нужно. Ни больше, ни меньше.

> Получилось еще меньше -- 1.6%

У меня есть ощущение что вы, как и большинство линуксодидов, предпочитаете задрачиваться и брать на себя те функции, которые легко бы сделал за вас ОС

Ничего не понял, но звучит очень ынтерпрайзно.

Давай свою статистику, скрипт я выложил.

> Давай свою статистику, скрипт я выложил.

Не получится, потому что я задрочился и разложил все с симлинками. Думаю не более 2-4% будет

Но по моему лазить по симлинкам это тоже нагрзука для системы, а мне хотелось бы побыстрее

Сто гигов? Счас в ноутбуках уже винты в три-пять раз больше :-)

Да-да я сейчас для тебя пойду корпоративный сторадж лопатить.

Давай свою статистику. Зачем эти странные теории и примеры с клонами вирт. машин и торентами? Это все-равно что делать бэкап оракла средствами ФС, а не его собственным утилем.

Но по моему лазить по симлинкам это тоже нагрзука для системы, а мне хотелось бы побыстрее

В сад!

>> Сто гигов? Счас в ноутбуках уже винты в три-пять раз больше :-)

>Да-да я сейчас для тебя пойду корпоративный сторадж лопатить.

А чо бы и нет? Вдруг выяснишь, что за счет дедупликации можно кучу бабла сэкономить? Глядишь, премию дадут :-)

> Вдруг выяснишь, что за счет дедупликации можно кучу бабла сэкономить?

Щас! На закупке железа можно поднять куда больше откатов и комиссионных, чем какая-то жалкая премия :-)

> Щас! На закупке железа можно поднять куда больше откатов и комиссионных, чем какая-то жалкая премия :-)

Вот так вот и открываются истинные причины противления прогрессу :-)

linuxfan> параноидальным цитированием лицензии в каждом файле

Ты мудак. Цитирвоание лицензии в каждом файле необходимо по юридическим причинам.

linuxfan> Тем, что стоимость "распаковки" практически нулевая.

А как же diff? Нулевая, говоришь? Значит подтверждаешь то, что ты ламер.

ZFSych> А кто сказал, что дедупликация исключает сжатие? Так что можно получить профит сначала от сжатия, а потом еще и от дедупликации

После сжатия от дедупликации ничего хорошего не выйдет - только дополнительные тормоза. После сжатия нечего дедуплицировать.

Как бы намекают: сжатие больше не нужно. Незачем тратить ресурсы CPU на сжатие - лучше/быстрее будет работать дедупликация. Ещё инкрементные бэкапы сами собой будут образовываться простым копированием, без использования спец.утилит.

Трата ресурсов CPU порой лучше, чем трата времени на считывание данных с накопителя. А распаковка для сегодняшних CPU - мелочь.

Как бы намекают: сжатие больше не нужно. Незачем тратить ресурсы CPU на сжатие - лучше/быстрее будет работать дедупликация

Н-да, фанатики, такие фанатики.

Сжатие и дедупликация вещи ортогональные.

linuxfan> CPU -- Intel(R) Pentium(R) 4 CPU 3.20GHz

Засунь себе в задницу этот процессор и проведи тестирование на многоядерных многопоточных спарках.

as33> Место под диски VM ведь уже зарезервировано, откуда прилетит

Ошибаешься. С такой ФС место не зарезервировано. Как шаг влево, шаг вправо - и уже требуется больше места.

ZFSych> Вдруг выяснишь, что за счет дедупликации можно кучу бабла сэкономить?

Экономия денег на надёжности и энтерпрайз - понятия несовместимые.

Сжатие и дедупликация вещи ортогональные.

В общем, да.

Однако.

Дедупликация и так учитывает уникальные блоки данных и не увеличивает количество дубликатов, а наоборот — меньшает их (как бы логично из названия механизма). Улучшается скорость ввода-вывода, так как при операциях с одинаковыми файлами из носителя в память загружается только один блок данных (например, лицензионное соглашение в куче текстовых файлов будет одно, и часть блоков данных, содержащих его, одинаковы). Алгоритмы компрессии не задействуются — меньше расход ресурсов CPU.

Блоки данных нельзя сжать по отдельности, поэтому в ФС сжимаются файлы, состоящие из этих блоков. Алгоритм сжатия слишком интеллектуальный, чтобы не учитывать уникальность блоков, а жать весь файл наиболее оптимальным образом. Например, два текстовых файла, отличающихся несколькими байтами, будут ужаты и иметь абсолютно все отличающиеся блоки данных. ВСЕ блоки данных — что в случае дедупликации быть не могло в принципе. Для систем контроля версий сжатие на лету будет накладно как по объёму занимаемого места, так и по времени доступа. Так что для /usr/src дедупликация — самое то, если нужен быстрый доступ к исходникам и их модификация.

Разреженные файлы. Естественно, такие вещи имеют много одинаковых блоков сами по себе и ужимаются очень хорошо. Так что дедупликация здесь работает как простое RLE-«сжатие» данных, а сжатие на лету алгоритмом GZIP может ещё больше уменьшить занимаемое файлом место.

Обычные бинарные файлы, файлы архивов и мультимедиа файлы — здесь оптимизируются только заголовки (и то не все). Дедупликация и сжатие вообще не помогут НИКАК.

Обычные бинарные файлы, файлы архивов и мультимедиа файлы... Дедупликация и сжатие вообще не помогут НИКАК.

Первая умная мысль. Это именно то что я хотел показать своим скриптом — в обычных не связанных между собой файлах фактически нет одинаковых блоков.

Т.е. дедупликация может быть эффективной на фс с особым содержимым.

Вопрос что это за содержимое такое, чтобы получить профит от дедупликации?

Лицензии в текстовых файлах — это лажа, не стоящая ничего. Я могу предложить вариант хранения лицензии в отдельном файле и автоматическое вклеивание его в начало каждого файла при экспорте проекта из VCS. Это кстати избавляет кодера от необходимости вставлять лицензию в каждый файл и в случае изменения лицензии менять придется только в одном файле.

Системы контроля версий хранят дифы, а не предыд. версии файлов. Бинарные документы (типа pdf, doc, odt), даже отличаясь в тексте на одну букву, в бинарном виде будут сильно различаться.

Разреженные файлы, на то и разреженные, что не занимают блоков на диске (имеют дыры), т.е. тут вообще нечего дедуплицировать.

Клонирование вирт. машин — производится средствами самих вирт. машин.

Что еще?

З.Ы. Я не пытаюсь намерено дискредитировать идею автоматической дедупликации, а хочу найти ей область применения с максимальным эффектом (с экономией > 10% места хотя бы)