ZFS не нужна

>>на многоядерных многопоточных спарках.
AFAIK сейчас санки ставят на сторадж сервера оптероны, но да
>Засунь себе в задницу этот процессор
=)

прогнал по своему 2TB ZFS массиву, из которого занято ~700GB, таки уникальных блоков 0.8% :(

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

Ой ли?

Один и тот же блок двух одинаковых файлов сжимаем одним алгоритмом с одинаковыми параметрами и начальными значениями и получаем разные сжатые блоки?

Как алгоритм называется, не подскажете?

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

Поясните мысль, пожалуйста. Где вы увидели экономию денег на надежности? Почему не совместимы экономия денег и энтерпрайз?

Вы не на нефтяной игле случайно сидите?

> Блоки данных нельзя сжать по отдельности, поэтому в ФС сжимаются файлы, состоящие из этих блоков.

Это почему это нельзя отдельные блоки сжать отдельно?

Если жать файлы целиком на уровне ФС, то каким образом вы будете эффективно реализовывать перемещение по файлу, если вам вдруг понадобится переместиться в конец файла перед последним записанным байтом? Весь файл будете распаковывать?

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

В случае разреженных файлов в обычном понимании (то есть имеющих большие последовательности нулей), вовсе нет необходимости эти последовательности нулей хранить. В ZFS именно так и сделано:

http://blogs.sun.com/bonwick/en_US/entry/seek_hole_and_seek_data

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

Если такой файл один - то да, не помогут. Если их много одинаковых - то сжатие может и не поможет, а вот дедупликация вполне.

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

Например:

- билд-сервер для оравы разработчиков или основанных на одной базе проектов
- виртуализационные среды всякие
- всякие файловые сервисы
- бэкап-серверы для оравы одинаковых машин

Мало?

На тех же хостингах там где всякие phpBB повторяются, потому что не зависит дедупликация на уровне блоков файлов от порядка записи этих файлов :-) Оверселлинг - это не так уж и плохо, поскольку можно дифференцировать цены... Хотите гарантии - получите, но по той же цене, что и раньше. Не смущает дедупликация - пожалуйста, и дешевле.

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

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

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

Производится-то оно производится, но:

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

ЗЫ. Клонирование виртуальных машин средствами самой системы виртуализации - это не пример ли комбайна-все-в-одном? :-) Двойные стандарты они такие ... двойные :-)

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

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

Давай свою статистику

Пожалста:

# zdb -S tank
Simulated DDT histogram:

bucket              allocated                       referenced          
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
------   ------   -----   -----   -----   ------   -----   -----   -----
     1     936K   92.4G   92.3G   92.3G     936K   92.4G   92.3G   92.3G
     2    49.9K   3.15G   3.15G   3.15G     113K   6.80G   6.80G   6.80G
     4     9.9K    319M    319M    319M    48.1K   1.46G   1.46G   1.46G
     8    1.42K   43.1M   43.1M   43.1M    14.0K    449M    449M    449M
    16      319   11.8M   11.8M   11.8M    6.68K    255M    255M    255M
    32      114   5.56M   5.56M   5.56M    4.62K    221M    221M    221M
    64       47    298K    298K    298K    4.10K   32.1M   32.1M   32.1M
   128       24    147K    147K    147K    4.33K   35.1M   35.1M   35.1M
   256        8   5.50K   5.50K   5.50K    2.45K   1.69M   1.69M   1.69M
   512        3   1.50K   1.50K   1.50K    2.17K   1.08M   1.08M   1.08M
    1K        5   5.00K   5.00K   5.00K    7.23K   7.57M   7.57M   7.57M
    8K        1     512     512     512    14.1K   7.05M   7.05M   7.05M
  128K        1    128K    128K    128K     163K   20.4G   20.4G   20.4G
 Total     998K   95.9G   95.8G   95.8G    1.29M    122G    122G    122G

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

# zpool list tank
NAME     SIZE   USED  AVAIL    CAP  HEALTH  ALTROOT
tank     197G   122G  74.6G    62%  ONLINE  -

ну не мети ты бисер перед свинями

давай лучше поможем в поддержке работы zfs в мак оси - но на уровне ядра