LINUX.ORG.RU

В ZFS появилась поддержка исключения дубликатов

 ,


0

0

Jeff Bonwick, разработчик интересной во всех смыслах файловой системы нового поколения ZFS, в своём блоге сообщил о реализации следующего новшества — системы автоматического распознавания и объединения дубликатов!

Технология работает на уровне блоков данных, что, по оценке разработчиков Sun, является более универсальным и менее ресурсоемким решением, по сравнению с вычислением дубликатов на уровне файлов или произвольных наборов байтов. Как известно, для каждого блока данных в ZFS вычисляется контрольная сумма по алгоритму SHA256. Если данная контрольная сумма уже присутствует в хэше, то запись такого же блока данных, который уже есть в хранилище, не производится, а создаётся ссылка на уже имеющийся блок данных. То есть, если в нескольких файлах присутствуют одинаковые блоки данных, то они будут сохранены на физический носитель только один раз.

>>> Подробности

★★★★★

Проверено: maxcom ()
Ответ на: комментарий от Ruth

> А преимущества дедупликации какие то сомнительные

Так и напрашивается(как уже заметили выше) для read only fs. Например для двд.Впрочем для медиа контента это не даст совпадений, а варез тоже как правило сильно различный.

roller ★★★
()
Ответ на: комментарий от frost_ii

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

Для реализации этой фичи не требуется писать ФС.

Так написали только небольшое расширение для ФС - чтобы облегчить труд. Не вижу в этом ничего плохого.

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

Ruth ★★
()
Ответ на: комментарий от Cosmicman

> лет 20 назад было бы актуально. сейчас при обьеме жд в терабайты оно нафиг не надо. нашли бы лучше более полезное применение ресурсам цпу :)

Ну блин, а размер оператки у вас совпадает с размером жесткого диска? У вас терабайты оперативки?

Дедупликация снижает нагрузку на дисковый кэш в оперативной памяти. Рассмотрим пример: пусть предоставляем VDS. Орендуем/покупаем реальную железку и впихиваем туда, скажем, 10 виртуальных машин. Потом эти виртуальные машины сдаём в оренду. Для начана на каждой виртуалке с помощью копирования разворачиваем одинаковое окружение (ос+веб сервер+бд). Если применить дедупликацию (и вспомнить что переустановкой ос на VDS особенно ни кто не занимается), то можно снизить нагрузку на кэш дисковой подсистемы в оперативной памяти в разы. Т.е если виртуальные машины начинают занимать на диске в 10 раз меньше, то и в кэше они начинают занимать меньше, а значит в кэш больше влазит.

HexGhost
()
Ответ на: комментарий от anonymous

А никто не подумал, что при нахождении блоков с одинаковым хешем, фс сравнит также и содержимое блоков? Таким образом, на коллизии пох.

+тормоза впрочем...

+10 все мысли один в один.

Но может быть и ускорение меньше записей на накопитель (это если оперативки много и ЦПУ простаивает).

Узко-специализированное применение типа: файлопомойка.

Вердикт один тормозаааа. Ентерпризе )))

winnersgroup
()
Ответ на: комментарий от jerry

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

ZFS не нужна (комментарий)

sdio ★★★★★
()

хмм... идея хорошая, но сомнительная..

есть файл юзера (A), пусть он будет fA, другой юзер (B) копирует такой же файл fB

сейчас fB ссылается на fA

юзер A редактирует файл

вопрос знатокам: что увидит юзер B когда откроет файл

ответов может быть 2:

1) то что туда нагадит юзер А, что совсем никуда не годится

2) копию своего файла

надеюсь что в случае с zfs сделали именно второй вариант, но тогда эта система будет давать профит только в read-only mode

shty ★★★★★
()
Ответ на: комментарий от roller

для двд

а в dvd приводах время позиционирования головки совсем страшное.... так что мимо

shty ★★★★★
()
Ответ на: комментарий от shty

>юзер A редактирует файл

ну непонятно чтоли что блок будет записан по-старинке? он уже не дедуплицируется соотв. будет иметь отдельную копию.

>вопрос знатокам: что увидит юзер B когда откроет файл

увидит те блоки которые остались общие - из общака. остальное - из своей копии

gigabito
()
Ответ на: комментарий от shty

>но тогда эта система будет давать профит только в read-only mode

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

gigabito
()
Ответ на: комментарий от sdio

О, здорово! Ну, 3.5% это уже что-то. К тому же дедубликацию можно будет вешать на отдельный каталог, не затрагивая всю ФС, как я понял. Может, кому и сгодится.

jerry
()
Ответ на: комментарий от winnersgroup

> А никто не подумал, что при нахождении блоков с одинаковым хешем, фс сравнит также и содержимое блоков?

А ни кто тут не подумал прочитать о фиче внимательно и ВНЕЗАПНО узнать, что по-умолчанию сравнения данных не происходит? Происходит оно только если его специально включить, а так проверки не происходит. А то думают они тут.

Ещё больше бесят размышления на тему максимального размера блока с уникальным хэшем. Хэш это число. Номер. Блок с данными это тоже число. Да, почему бы не представить это как одно огромное число, а? А теперь скажите сколько раз 1 поместится в миллиарде? Правильно, 1 миллиард раз. То же самое и с хэшем. Если блок больше хэша в 16 раз (например, 4Кб и хэш на 256 байт), то на каждый хэш в среднем приходится 16 разных блоков. 16! Т.е. в худшем случае файл размером в 64 Кб будет иметь 16 блоков с одинаковым хэшем. Другое дело, что вероятность этого крайне мала, но она есть.

anonymous
()
Ответ на: комментарий от gigabito

увидит те блоки которые остались общие - из общака. остальное - из своей копии

плата за такой подход: дикая фрагментация, соотв. снижение скорости обслуживания клиентов, что не всегда хорошо

shty ★★★★★
()
Ответ на: комментарий от shty

>плата за такой подход: дикая фрагментация, соотв. снижение скорости обслуживания клиентов, что не всегда хорошо

но и не всегда плохо. zfs set dedup=off для нужных разделов никто не запрещал

gigabito
()
Ответ на: комментарий от anonymous

Блять, я математик. Какой там нахер 16. Основание системы счисления в 16 степени раз. А это уже на много хуже, не так ли?

anonymous
()
Ответ на: комментарий от gigabito

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

завтра эти носители уже будут по 60, а в следующем году по 25... что экономим-то? а вот количество пользователей/нагрузка на сервер растёт чуть ли не экспоненциально... соотв. чем быстрее юзера обслужили, тем скорее смогут начать обслуживать следующего, comprende?

shty ★★★★★
()
Ответ на: комментарий от anonymous

Блять, я математик.

в квотесы, однозначно :)

shty ★★★★★
()
Ответ на: комментарий от gigabito

но и не всегда плохо. zfs set dedup=off для нужных разделов никто не запрещал

ну, здесь нельзя не согласиться

shty ★★★★★
()
Ответ на: комментарий от shty

короче опять задача синтеза оптимальных параметров хранилища по характеристикам speed и size :)

shty ★★★★★
()
Ответ на: комментарий от shty

>завтра эти носители уже будут по 60, а в следующем году по 25

да не будут они по 60 и по 25 тем более. лет через 5 - возможно. но возрастут объёмы и опять будем хныкать но уже про терабайты.

>соотв. чем быстрее юзера обслужили, тем скорее смогут начать обслуживать следующего

а тут уже выбирается по ситуации, что быстрее и дешевле - SAS с dedup'ом или SATA. ставятся опыты, делаются рассчёты. думали нормальное проектирование систем это чё нравится, то и поставил? хрен там.

gigabito
()

Вспоминается эпичный тред на ixbt.com, в котором обнаружили, что не любой файл можно считать с CD-ROM.

Оказывается, многие производители CD-ROM начало дорожек обозначают ~64-байтовым пилот-тоном (т.е. 320 бит). При считывании, поток XOR-ится по какой-то маске с "хорошим распределением", и если после XOR получается FFFFFFFFFFFFFFFFF..., считается, что обнаружен пилот-тон.

А если в файле будет набор данных, который после XOR с этой хорошо распределенной маской даст FFFFFFFFF..., то сии данные будут считаться пилот-тоном, и прочитаны не будут. Вероятность такого совпадения 2^(-320). И всеравно обнаружили _случайно_, без направленного перебора.

Чорт, щас не могу найти эту статью.

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

xintrea
()
Ответ на: комментарий от www_linux_org_ru

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

madcore ★★★★★
()
Ответ на: комментарий от sdio

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

А ничего, что в ZFS размер блока изменяемый?

iZEN ★★★★★
() автор топика

Нде :(

«Для систем, на которых не достаточно проверки по хэшу SHA256, предусмотрен режим повышенной надежности...»

А для остальных систем, видимо, пофигу, что в файле будет записано не то, что туда записали! Похоже, кто-то сошёл с ума.

guitarist ★★
()
Ответ на: комментарий от HexGhost

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

frost_ii ★★★★★
()

Сейчас всё выглядит более-менее хорошо. Но допустим, SHA256 оказывается взломан. Тогда, если нам тем или иным образом стал известен хеш некоторого файла (поскольку по хешу нельзя восстановить файл, то вполне возможна ситуация, когда владелец файла отправит хеш через незащищённый канал; и файл может помещаться в одном блоке данных), то мы генерируем файл с таким же хешем, записываем его на диск, система сравнивает хеши, считает, что данные те же и вместо нашего содержимого делает ссылку на блок чужих данных. Читаем свой файл, и получаем их.

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

askh ★★★★
()
Ответ на: комментарий от gigabito

Домашнее задание - поредактируйте какой-нибудь файли посмотрите, сколько общих мест после этого осталось.

frost_ii ★★★★★
()
Ответ на: комментарий от iZEN

К чему этот вопрос? Ннаписание такой утилиты невозможно в принципе?

jerry
()
Ответ на: комментарий от gigabito

да не будут они по 60 и по 25 тем более

будут, батенька, будут... динамика тут очень явная

и да, к цифрам не привязывайтесь, они от фонаря, утрированные

выбирается по ситуации, что быстрее и дешевле - SAS с dedup'ом или SATA

вовсе и нет, проектирование хранилищ информации несколько шире, чем описанный случай

умали нормальное проектирование систем это чё нравится, то и поставил? хрен там.

воистину не понимаю с чего Вы это удумали?..

shty ★★★★★
()
Ответ на: комментарий от legolegs

>>блок должен быть размером не больше размера хэша :)

>Вообще-то нет. man сжатие_данных


Вообще-то да. man принцип_Дирихле

Manhunt ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> Значит, на 1Гбайт будет 1 ошибка за время от 2 до 5 часов.

Как тогда получается многолетний аптайм? Не понимаю.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

>> Значит, на 1Гбайт будет 1 ошибка за время от 2 до 5 часов.

>Как тогда получается многолетний аптайм? Не понимаю.


Объяснений можно было бы много напридумать, но как тогда memtest умудряется отработать хотя бы сутки без ошибок?

madcore ★★★★★
()
Ответ на: комментарий от askh

>и вместо нашего содержимого делает ссылку на блок чужих данных. Читаем свой файл, и получаем их.

возможен будет и обратный вариант: вышло критическое обновление. подготовим по известному его хэшу какой-нибудь руткит, записываем в свой home и ждём, когда админ нашего хостинга будет обновляться >:)

anonymous
()
Ответ на: комментарий от frost_ii

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

m1ke
()
Ответ на: комментарий от www_linux_org_ru

>Предположим размер блока 4К, размер ФС 4Т, имеем .... коллизия имеет вероятность 1/10^51 в месяц.

Допустим, размер блока 4000 байт. Это 32000 бит. Размер хэша 256 бит. Итого существует 2^32000 различных блоков и только 2^256 хэшей. На каждый хэш - по 2^31744 коллизий.

То есть при совпадении хэшей данные будут совпадать с вероятностью 1/7.873763345e+9555. Если речь о равномерно распределённых случайных данных, конечно.

Ну а сами совпадения хэшей, да, будут происходить редко. Различных хэшей - 115.792089237e+75, а 4KB блоков в 4TB файловой системе - 1e+9.

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

fffgh ★★
()
Ответ на: комментарий от HexGhost

> Если применить дедупликацию (и вспомнить что переустановкой ос на VDS особенно ни кто не занимается), то можно снизить нагрузку на кэш дисковой подсистемы в оперативной памяти в разы.

Нормальные системы виртуализации пользовательскую дельту хранят отдельно от мастер-образа. Никакого зфс для этого не надо.

Итого: в общем случае оно на фик не надо, а там, где оно действительно надо, оно уже есть, с блекджеком и покемонами.

LamerOk ★★★★★
()
Ответ на: комментарий от shty

>будут, батенька, будут... динамика тут очень явная

сильно SSD подешевели за год?

>воистину не понимаю с чего Вы это удумали?..

ну ето я иронизировал про 90% ресурса которые привязывают любое ноу-хау к своей коллекции мп3 и в панике орут что есть вероятность коллизии и потери новой серии гарри поттера.

gigabito
()
Ответ на: комментарий от m1ke

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

frost_ii ★★★★★
()
Ответ на: комментарий от frost_ii

>Очень сильно. От нереально дорого, до просто дорого.

ето может какие-то пафосные интели там или прочее. а рабочий например мтрон как был 160 за 32 гига так и остался 140.

ладно, приведем другой пример, SSD технология новая, дешевеет быстрее. посмотрите динамику цен на SAS/SATA. 2ТБайтники за год практически не упали.

gigabito
()
Ответ на: комментарий от Ruth

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

Так можно просто хардлинки сделать, не?

fffgh ★★
()
Ответ на: комментарий от madcore

> Объяснений можно было бы много напридумать, но как тогда memtest умудряется отработать хотя бы сутки без ошибок?

мне самому интересно.

методика тестирования "записал что-то и тут же прочел" вполне может работать без ошибок сутками, так как читается *тут же*

так что надо

1. заполнить память каким-либо паттерном

2. далее его только читать, причем последовательно, чтобы кэш проца не влиял

и тогда уже за несколько часов можно увидеть, идут ошибки или нет

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

> методика тестирования "записал что-то и тут же прочел" вполне может работать без ошибок сутками, так как читается *тут же*

Вообще-то у мемтеста прямо противоположная логика - он записывает всю память паттерном, а потом считывает и сверяет.

> так что надо


Не ты один такой умный. ))

Кроме того, аппартаня коррекция ошибок есть на шине, без всякого ECC. Так что чего там посчитали эти крендели - нифига не понятно. В пэдээфке про методику фиксации ошибок ничего не сказано.

LamerOk ★★★★★
()
Ответ на: комментарий от anonymous

> возможен будет и обратный вариант: вышло критическое обновление. подготовим по известному его хэшу какой-нибудь руткит, записываем в свой home и ждём, когда админ нашего хостинга будет обновляться >:)

клево :-)

хотя при нынешних мощностях вряд ли это реально даже в сети из 1М машин

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от gigabito

Ок, согласен. Механика терабайтного размера заа этот год не подешевела. Так и запишем.

Но вот вопрос - сколько _реально_ можно сэкономить от ёмкости диска при применении такой технологии? И в каком секторе её можно применить? Домашний комп - бесполезно. У меня (полагаю, что и у подавляющего большинства пользователей) нет файлов с частично совпадающим содержимым. Ынтырпрайз - чревато. Будет очень много охотников за коллизиями.

frost_ii ★★★★★
()
Ответ на: комментарий от frost_ii

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

Такие файлы есть везде и у всех. Вопрос в их доле, относительно других.

LamerOk ★★★★★
()
Ответ на: комментарий от frost_ii

>Но вот вопрос - сколько _реально_ можно сэкономить от ёмкости диска при применении такой технологии?

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

Тут вот пример: http://www.linux.org.ru/jump-message.jsp?msgid=4196890&cid=4197111

fffgh ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.