03.11.2009 10:16
В ZFS появилась поддержка исключения дубликатов
|
 |
|
Jeff Bonwick, создатель файловой системы ZFS, сообщил в своем блоге о реализации интересного новшества - системы автоматического распознавания и объединения дубликатов. Технология поддерживает работу на уровне блоков данных, что по оценке разработчиков Sun является более универсальным и менее ресурсоемким вариантом, по сравнению с вычислением дубликатов на уровне файлов или произвольных наборов байт. Для каждого блока вычисляется контрольная сумма SHA256, если данная контрольная сумма уже присутствует в хэше, производится создание ссылки на уже имеющийся набор данных. Иными словами, если в нескольких файлах присутствуют аналогичные блоки данных, то они будут сохранены на физический носитель только один раз.
Представленная возможность позволит существенно уменьшить потребление дискового пространства и увеличить производительность - вместо копирования блоков будет лишь изменена запись в соответствующей таблице. Наиболее заметный эффект от технологии исключения дубликатов можно наблюдать при организации резервного копирования, в больших репозиториях исходных текстов и в системах виртуализации с большим набором типовых гостевых окружений. В таких системах может быть достигнута экономия дискового пространства в разы.
Включение новшества производится командой "zfs set dedup=on имя_пула" или "zfs set dedup=on имя_пула/отдельная_директория". Для систем, на которых не достаточно проверки по хэшу SHA256, предусмотрен режим повышенной надежности, при котором производится дополнительное полное сравнение блоков данных при совпадении хэша. Данный режим включается через "zfs set dedup=verify имя_пула". Вместо SHA256 в сочетании с режимом verify можно использовать менее надежный, но более быстрый метод вычисления контрольной суммы - fletcher4 ("zfs set dedup=fletcher4,verify имя_пула").
|
|
|
- Главная ссылка к новости (http://blogs.sun.com/bonwick/en_US/entry...)
- Перевод на русский язык заметок из блога Jeff Bonwick
|
| Тип: К сведению |
| Ключевые слова: zfs, (найти похожие документы) |
| При перепечатке указание ссылки на opennet.ru обязательно |
| Реклама |
|
|
|
| |
| 1.2, uldus, 10:36, 03/11/2009 [ответить] [смотреть все]
| +1 +/– |
Меня удивляет, как такое простое и казалось бы очевидное решение раньше не придумали. По сути автоматическая расстановка хардлинков на блочном уровне.
|  | | |
| 1.3, letsmac, 10:39, 03/11/2009 [ответить] [смотреть все]
| +/– | |
Интересно насколько упадёт скорость записи в таком режиме.
>>В таких системах может быть достигнута экономия дискового пространства в разы.
Интересно как система будет правильно отрабатывать многопотоковую запись/ дефрагментацию в таких системах.
|  | | |
| 1.4, Nexor, 10:54, 03/11/2009 [ответить] [смотреть все]
| +1 +/– |
Мне страшно от слов "менее надежный". Как можно обойтись без точной проверки блоков? Если у нас вдруг окажутся разные данные с одинаковым хэшем то полный пипец будет
|  | | |
| 1.5, QuAzI, 10:55, 03/11/2009 [ответить] [смотреть все]
| +/– |
дефрагме... что простите?
А почему скорость должна упасть? Там хеши вычисляются, поиск по хешам милое дело, это вам не обход дерева каталогов с сравнением размера с последующим сравнением содержимого, как в винде все эти чистилки/удалялки копий делают.
|  | | |
| 1.12, Knuckles, 11:26, 03/11/2009 [ответить] [смотреть все]
| +/– |
Вставка хардлинка на блок другого файла это фактически фрагментация. При хорошей "оптимизации" пространства скорость чтения должна ощутимо упасть.
|  | | |
| 1.15, ameoba32, 11:30, 03/11/2009 [ответить] [смотреть все]
| +1 +/– |
Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да и сколько там можно сэкономить, дупликатов не так много, да и при текущей цене $/Tb.
|  | | |
| 1.25, webbeans, 11:49, 03/11/2009 [ответить] [смотреть все]
| +/– | |
>Для систем, на которых не достаточно проверки по хэшу SHA256, предусмотрен режим повышенной надежности, при котором производится дополнительное полное сравнение блоков данных при совпадении хэша.
Круто, то есть, по сути, будут две контрольные суммы (два хэша) - SHA256 и ещё один?
|  | | |
| 1.42, barmaglot, 13:27, 03/11/2009 [ответить] [смотреть все]
| +/– | |
http://en.wikipedia.org/wiki/SHA256
Algorithm and
variant Output size (bits) Internal state size (bits) Block size (bits) Max message size (bits) Word size (bits) Rounds Operations Collisions found
------------------------------------------------------------------------
SHA-256/224 256/224 256 512 264 − 1 32 64 +,and,or,xor,shr,rot None
|  | | |
| 1.43, barmaglot, 13:44, 03/11/2009 [ответить] [смотреть все]
| +/– | |
Похоже уже все лоровцы сюда перебрались. "Фключить моск" никому идея не приходит. Пишут что попало без знания предмета.
О вероятности коллизий на пространстве 2^64 для SHA256 алгоритма можно почитать тут: http://www.springerlink.com/content/t1087808x7506841/
Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.
> Круто, то есть, по сути, будут две контрольные суммы (два хэша) - SHA256 и ещё один?
Для сравнения блоков по хешу используется тот-же самый хеш, что и для проверки целостности блока. Сравнение блоков на совпадение про "повышеных запросах надёжности", происходит только однажды про создании ссылки !
|  | | |
| 1.46, Aleksey, 14:07, 03/11/2009 [ответить] [смотреть все]
| +/– |
Пример реального применения:
1) вы занимаетесь монтажом видео. Периодически делая копии полученных результатов, чтобы позже иметь возможность откатить изменения. Для такого случая экономия может быть достаточно весомой.
2) все ваши пользователи работают под терминалками внутри одного компьютера с набором похожих данных. Тут тоже возможен выйгрыш.
3) Внутри многих файлов можно обнаружить целые массивы состоящие из символов с кодом 0. Вероятно и тут можно получить выйгрыш. Такого рода крупные разряженные файлы будут получаться достаточно маленькими.
|  | | |
| 1.58, аноним, 15:25, 03/11/2009 [ответить] [смотреть все]
| +/– |
Эм, а что, если по умолчанию используется чексуммы fletcher4, а в dedup sha256, будут считаться сразу две чексуммы?
|  | | |
| 1.65, аноним, 15:51, 03/11/2009 [ответить] [смотреть все]
| +1 +/– |
Чего-то я не совсем понял, видать и в самом деле просто туплю.
В новости "...Наиболее заметный эффект от технологии исключения дубликатов можно наблюдать при организации резервного копирования... В таких системах может быть достигнута экономия дискового пространства в разы...". Разве смысл резервного копирования не заключается еще и в том, что куски данных избыточно дублируются (физически), чтобы если сдохнет один блок, данные можно было взять в другом месте? А так все "ссылки" ведут на один блок, он сдох - и сдохли все 15 "ссылок" на этот блок из разных мест файловой системы
|  | | |
| 1.77, jSnake, 16:51, 03/11/2009 [ответить] [смотреть все]
| +/– |
Меня вот что интересует.
Вот ZFS обеспечивает дедупликацию на уровне ФС, Оракл на уровне БД, сторэджи (типа Hitachi) вообще чуть ли не на уровне контроллеров. Кстати, сжатия это тоже касается (ну модно сейчас дедуплицировать и сжимать).
Внимание, вопрос: а насколько эффективно будет всё ЭТО работать и сколько ресурсов пожирать в реальной системе? Зачем мне три(!!!) технологии дедкпликации/сжатия на одном несчастном куске данных? Это ведь какая мука для инженера выбрать)
|  | | |
| 1.84, аноним, 17:16, 03/11/2009 [ответить] [смотреть все]
| +1 +/– | |
Замечательно. Мало того, что ZFS даже не пытается выделять непрерывные куски места под sparse файлы, т.е. файл, скачанный торрентом (где куски приходят черти в каком порядке, и в таком же ложатся на диск, судя по количеству seek'ов при чтении) фрагментирован просто неимоверно, так это теперь еще и его копированием не вылечишь. Way to go.
Алсо умиляют идиоты, которые говорят что ZFS не подвержена фрагментации.
|  | | |
| |
| |
| 3.149, аноним, 06:37, 05/11/2009 [ответить] [смотреть все]
| +/– | |
>Иди учи матчасть, а потом перечитай свое сообщение и отредактируюй как следует.
Сначала напиши в поле "сообщение", что хотел сказать, потом жми "Отправить", позорище.
|  | | |
|
|
| |
| |
| |
| 4.150, Andrey Mitrofanov, 09:24, 05/11/2009 [ответить] [смотреть все]
| +/– | |
>/dev/zero хотели сказать?
Гы, ес-тестно. Оговорочки по англо-русскому словарю, наверное...
dull
[dʌl]
1. _a.
1) тупой; глупый
2) скучный; монотонный; dull beggar (или fish) скучный человек
3) тупой; притупленный; dull pain тупая боль; dull of hearing тугой на
ухо
4) тупой, неотточенный
5) тусклый
6) пасмурный
7) неясный; dull sight слабое зрение
8) безрадостный, унылый, понурый
9) вялый (о торговле)
10)неходкий, не имеющий спроса (о товаре)
2. _v. притуплять(ся); делать(ся) тупым, тусклым, вялым, скучным; to dull
the edge of one's appetite заморить червячка
/dev/dull - /me тупит %)
|  | | |
|
| 3.129, User294, 08:14, 04/11/2009 [ответить] [смотреть все]
| +/– | |
>'cat /dev/dull > $FILE'
Что за девайс у вас такой хитрый? Он показывает при этой операции дулю? Или что за ...? :)
|  | | |
|
|
| |
| 2.146, QuAzI, 00:50, 05/11/2009 [ответить] [смотреть все] [показать ветку]
| +/– |
>не очень понятно можно ли использовать по дефолту быстрый fletcher4, и, если
>такой блок уже есть, то сверять еще и sha256? или ничем
>не будет отличаться от verify?
Если я правильно понял, то как раз и имелось ввиду что можно использовать fletcher4 для ускорения и второй алгоритм можно прикрутить.
|  | | |
|
|
|
| Ваш комментарий |
|
|
| |
|