А теперь представь, например, ситуацию, когда какой-нибудь "придурок" шлёт в корпоративную рассылку письмо с аттачем 'Я и моя сраная кошка.mp4' о 24.2 мегабайтах, подумай как тут поможет дедупликация на уровне ФС почтового сервера и перестань постить фигню.
Фича безусловно интересная и во многих случаях нужная, но в статье говорится в том числе и о бэкап серверах... Вот лежит у нас кучка полных бэкапов чего либо, а тут раз! и бэд. И усё Х_х. Короче для простых смертных оно врядли потребуется в обозримом будущем без сановского железа или его аналогов а-ля х4540.
Есть у тебя Соляра с Virtualbox. Установив Гостевую ОС в один из zfs пулов, клонируем этот пул, получаем две Гостевых ОС. Места же они на диске занимают как одна плюс diff в блоках разницы между ними.
Круто? Круто! А Фанатеги GNU-only остаются в рядах простых смертных.
у нас ключь 256 используется для этого. вычесление его необходимо для работы FS. Поиск же, вещь простая. Осообенно если под этом отдать кэш метров так под 100
> подумай как тут поможет дедупликация на уровне ФС почтового сервера
Никак. "ZFS provides block-level deduplication" (c) цитата из бложека по ссылке. С учетом того, что в mailbox'е сообщения не выравнены по началу блока, никаких преимуществ.
> Фрагмент файла определённого размера, что же ещё?
Ну так бы и говорили
пробежал по диагонали. Думаю что имеено на уровне блоков FS ищеться дублирования. Потому что блоков FS хоть и много. но не так много, как всевозможных блоков файлов разной длины.
Кроме того, дубликаты как я понял ищутся на уровне пулов, а не ФС
#!/usr/bin/perl -w
use strict;
use Digest::SHA qw(sha256_hex);
my $block;
my $bs = 8192;
my $bc;
while (my $source = <STDIN>) {
chomp $source;
open (IN,$source) or die "Cannot read file; $!\n";
while ($bc = read(IN,$block,$bs)) {
my $digest1 = sha256_hex($block);
print $digest1 . "\n";
}
close IN;
}
запуск
$ find /home -xdev -type f | ./sha256_8k_block.pl > /tmp/sha256_8k_block.txt
Результат на 5.5Г разделе
$ wc -l sha256_8k_block.txt
727700
$ sort sha256_8k_block.txt | uniq -d | wc -l
25745
$ bc -lq
25745/727700 * 100
3.537
Итог: 3.5% экономии
Стоит ли оно того? ИМХО нет
>Никак. "ZFS provides block-level deduplication" (c) цитата из бложека по ссылке. С учетом того, что в mailbox'е сообщения не выравнены по началу блока, никаких преимуществ.
Тебе GNUтый конъюнктивит помешал почитать дальше?
>Byte-level dedup is in principle the most general, but it is also the most costly because the dedup code must compute 'anchor points' to determine where the regions of duplicated vs. unique data begin and end.
Представь себе что у тебя 10 виртуальных машин по 8Гб каждая. Получаем 80Гб на диске без дедупликации. А теперь включаем дедупликацию и добавляем ещё одну VM. Резултат?
> The second allows the administrator to select a threshhold afterwhich
> 2 copies of a block are stored rather than 1. For example, if many
> duplicate blocks exist deduplication would reduce that count to just 1;
> at some threshhold, it becomes desirable to have multiple copies to
> guard against the multiplied effects of the loss of a single block.
> The default value is '100'.
А чем оно лучше ФС с паковкой? Ведь сжатию подлежат не только дубликаты, следовательно эфективность в плане объема должна быть лучше.
/me вспомнил STACKER из PC-DOS, который когда-то позволял мне жить с весьма ограниченным объемом диска, например мог уместить 640МБ цд на 200МБ винт...
>Представь себе что у тебя 10 виртуальных машин по 8Гб каждая. Получаем 80Гб на диске без дедупликации. А теперь включаем дедупликацию и добавляем ещё одну VM. Резултат?
В один прекрасный и непредсказуемый день место на разделе кончается, виртуальная машина в непонятках, где ее 8ГБ.
Все замеры производились внутри tmpfs, чтобы наглядно было видно, что даже gzip имеет весьма ненулевое время распаковки. Размер данных — 22MB. CPU — Intel(R) Pentium(R) 4 CPU 3.20GHz
$ gzip -9c nmap-4.76.tar > nmap-4.76.tar.gz
$ time cat nmap-4.76.tar > /dev/null
real 0m0.012s
user 0m0.000s
sys 0m0.012s
$ time gzip -dc nmap-4.76.tar.gz > /dev/null
real 0m0.249s
user 0m0.248s
sys 0m0.000s
Вообще-то, гнутый коньюктивит заставляет меня читать всю статью за один раз. Byte-level dedup упоминается как один из теоретически возможных путей: "Data can be deduplicated at the level of files, blocks, or bytes".
А потом констатируется, что выбрали block-level dedup:
ZFS provides block-level deduplication because this is the finest granularity that makes sense for a general-purpose storage system. Block-level dedup also maps naturally to ZFS's 256-bit block checksums, which provide unique block signatures for all blocks in a storage pool as long as the checksum function is cryptographically strong (e.g. SHA256).
Для упертых фанатиков замечу, что переводится это примерно так: ZFS предоставляет дедупликацию на уровне блоков, поскольку она обеспечивает наилучшую эффективность для СХД общего назначения. Кроме того дедупликация на уровне блоков естественным образом укладывается в 256-битную контрольную сумму блоков ZFS, которая прдоставляет уникальные сигнатуры блоков до тех пор, пока функция вычисления контрольной суммы является криптографически сильной (напримр SHA256).
И да, управление дедупликацией на уровне on/off/verify это подтверждает, иначе были бы синтаксис dedup выглядет примерно так: dedup={off|block|byte|file}[,verify]