Jeff Bonwick, создатель файловой системы ZFS, сообщил (http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup) в своем блоге о реализации интересного новшества - системы автоматического распознавания и объединения дубликатов. Иными словами, если в нескольких файлах присутствуют аналогичные блоки данных, то они будут сохранены на физический носитель только один раз. Технология поддерживает работу на на уровне блоков данных, что по оценке разработчиков Sun является более универсальным и менее ресурсоемким, по сравнению с вычислением дубликатов на уровне файлов или произвольных наборов байт. Для каждого блока вычисляется контрольная сумма SHA256, если данная контрольная сумма уже присутствует в хэше, производится создание ссылки на уже имеющийся набор данных.
Представленная возможность позволит существенно уменьшить потребление дискового пространства и увеличить производительность - вместо копирования блоков будет лишь изменена запись в соответствующей таблице. Наиболее заметный эффект от...URL: http://blogs.sun.com/bonwick/en_US/entry/zfs_dedup
Новость: http://www.opennet.me/opennews/art.shtml?num=24092
круть, файлопомойки на freenas и freebsd зарулят теперь окончательно.
>круть, файлопомойки на freenas и freebsd зарулят теперь окончательно.Осталось самая малось, сделать нормальную поддержку SAN.
ага, подружить фрю с iSCSI так и не удалось
>ага, подружить фрю с iSCSI так и не удалосьА FreeNAS это разве не FreeBSD с поддержкой iSCSI?
Ну зачем же на всю страну кричать что руки мол растут из ... альтернативного места :)
Впрочем смотри FreeNAS - там оно уже настроено, как раз для кух^W начинающих.
PS: Просто для прикола было проверенно: ORACLE 10g RAC против них ничего не имеет, жрёт и работает :)
Где именно у вас подружить не получилось? У меня фряха раздаёт по iscsi zvol-ы, и достаточно быстро.
>Где именно у вас подружить не получилось? У меня фряха раздаёт по
>iscsi zvol-ы, и достаточно быстро.Раздовать, может она и научилась, если установить из /usr/ports/net/iscsi-target, а вот как подманитировать с iscsi... Извините, у меня на 7.х в кернел паник уходит, к сожалению... C EMC CX3-10 проблемы? Если у кого-нибудь получилось, буду рад об этом услышать...
Кто ж с CX серией юзает iSCSI для это FC есть.
Вот и стоит Solaris 10, пока нормальной поддержки SAN не будет. :-(
>Раздовать, может она и научилась, если установить из /usr/ports/net/iscsi-target, а вот как
>подманитировать с iscsi... Извините, у меня на 7.х в кернел паник
>уходит, к сожалению...8-CURRENT какой-то древний и 8-BETA1 полёт нормальный. Возможно в семёрке и были какие-то грабли, хотя думаю об этом в рассылках freebsd говорили бы.
>>Раздовать, может она и научилась, если установить из /usr/ports/net/iscsi-target, а вот как
>>подманитировать с iscsi... Извините, у меня на 7.х в кернел паник
>>уходит, к сожалению...
>
>8-CURRENT какой-то древний и 8-BETA1 полёт нормальный. Возможно в семёрке и были
>какие-то грабли, хотя думаю об этом в рассылках freebsd говорили бы.
>Спасибо, попробую.
Меня удивляет, как такое простое и казалось бы очевидное решение раньше не придумали. По сути автоматическая расстановка хардлинков на блочном уровне.
Дело не в идее. Дело в реализации. Понаписать это все так чтобы оно надежно работало
Если мне не изменяет память, нечто подобное, как и многое другое типа мнгновенных снимков и т. д. давно уже было реализовано в Plan9.
не изменяет.
>Меня удивляет, как такое простое и казалось бы очевидное решение раньше не
>придумали. По сути автоматическая расстановка хардлинков на блочном уровне.Хардилинки — только для файлов. А здесь работа идёт на уровне блоков данных. Так что — круче только яйца, замороженные в жидком азоте!
>>Меня удивляет, как такое простое и казалось бы очевидное решение раньше не
>>придумали. По сути автоматическая расстановка хардлинков на блочном уровне.
>
>Хардилинки — только для файлов. А здесь работа идёт на уровне блоков
>данных. Так что — круче только яйца, замороженные в жидком азоте!
>Не, яйцы это ещё не круть, круть это определений дуплей на уровне магнитных доменов, по намагниченности :)
Ну или хотя бы секторов.А создателю ZFS переквалифицыроваться в разработчика нового интерфейса и
контроллера дисков, SCZI - Small Computer ZFS Interface.Может на аппаратном уровне оно ещё интересней SCSI/SAS будет.
Интересно насколько упадёт скорость записи в таком режиме.>>В таких системах может быть достигнута экономия дискового пространства в разы.
Интересно как система будет правильно отрабатывать многопотоковую запись/ дефрагментацию в таких системах.
>дефрагментацию в таких системах.Забудьте это слово применительно к ZFS ;)
А мозк включить? От фрагментации данных на диске ZFS не спасет, а эта недоидея ее только повысит.
>А мозк включить?Включайте!
>От фрагментации данных на диске ZFS не спасет, а эта недоидея ее только повысит.ZFS не подвержена фрагментации. Правда анонимам это неведомо. :)))
Вы неуч. ZFS подвержена фрагментации также как и любая другая ФС.Пусть есть два файла, у которых каждый второй блок совпадает. ZFS не долга думая удаляет дубликаты, и получается, что при последовательном чтении для каждого второга блока надо лезть в другое место диска. Возражения будут?
Это не актуально. SSD и им подобные на дворе.
Лол. SSD пока в десять раз дороже и меньше по объему. Не актуален ваш максимализм.http://hardware.slashdot.org/story/09/10/24/1831238/No-Cheap...
Тем неменее Sun массивы во всю продаются с SSD дисками.
>Тем неменее Sun массивы во всю продаются с SSD дисками.Знаешь, Павлин, а порш кайен тоже вроде бы продается. Только почему-то не каждый день на улице его встречаешь. О чем это я? Да так, только недавно наблюдал корпоративщиков с суровой жабой, как раз по части HDD-ов. Прикольно, да? :)
>Это не актуально. SSD и им подобные на дворе.Дяденька, подарите мне SSD на 4 Тб, я с удовольствием отправлю жесткие диски в отставку. А то если их покупать за свой счет, можно пожалуй остаться без портков и с пустыми карманами :). SSD настолько злобно стоят что даже корпоративщики их используют сильно местами. А учтя что они еще и интенсивные записи в большом объеме не очень любят (число циклов перезаписи у флеша ограниченое и в ряде режимов SSD долго не протянут) - удовольствие получается дорогое и достаточно нишевое.
>Вы неуч. ZFS подвержена фрагментации также как и любая другая ФС.Судя по этому высказыванию Вы не знаете матчасти. Так что анон вперёд в гугл. И не порите больше чушь, ей больно.
Камон, расскажите же нам наконец - как это CoW да вдруг делается совсем без фрагментации?
>Камон, расскажите же нам наконец - как это CoW да вдруг делается
>совсем без фрагментации?Не "совсем", а "не критичны", не надо перегибать
>ZFS не подвержена фрагментации. Правда анонимам это неведомо. :)))CoW не подверженный фрагментации? Сойдет за анекдот сезона :))). А не расскажете как идея CoW уживается с отсутствием фрагментации?Чисто на уровне технологий :)
ЗЫ а вот объединение блоков - неплохо придумано, тем более что ФС 1 хрен этим занимается. Потенциальные грабли - небольшое повреждение может оказаться куда более деструктивно чем обычно. Но идея дедупликатора на уровне ФС - хороша. Она очевидна но вот на практике ее почему-то до сих пор никто не реализовал и я видел как минимум пофайловые дедупликаторы.
>>ZFS не подвержена фрагментации. Правда анонимам это неведомо. :)))
>
>CoW не подверженный фрагментации? Сойдет за анекдот сезона :))). А не расскажете
>как идея CoW уживается с отсутствием фрагментации?Чисто на уровне технологий :)Жидкие (от слова Жидкость) домены, вместо магнитной пыли, - удалил и дыра за сосалась,
а свободная жидкость переместилась в конец носителя. :)К примеру, ещё не придуманный состав находится в стабильном состоянии
и является носителем 0 или 1, для реализации блочной передачи,
они объединяются в макромолекулы. Эти молекулы находятся на некой
решетки (болванке), при удалении, например под воздействием рентгеновского
излучения (такая махонькая нейтронная пушечка), связи в этой молекуле разрушаются,
и они собственно, проваливаются сквозь решётку и съезжают в конец. Там они прилипают
к крайним. Свободной место затягивается естественным путём - силой межмолекулярного
притяжения. 8-)
>>ZFS не подвержена фрагментации. Правда анонимам это неведомо. :)))
>
>CoW не подверженный фрагментации? Сойдет за анекдот сезона :))). А не расскажете
>как идея CoW уживается с отсутствием фрагментации?Чисто на уровне технологий :)http://www.sun.com/emrkt/campaign_docs/expertexchange/knowle...
не верю! Где бенчмарки? У мну на ноуте тормозит ужасно, если сильно фрагментированный pool заполнен на 97-99%.
реализовано 8 лет назад в Bell Labs. Гуглить Venti.
Да, именно забудьте.
Дефрагментировать zfs невозможно.
А вот фрагментацию ее механизмы повышают. И очень сильно.
возможно, но только методом копирования данных на новый носитель и копирования их назад :-(
Дефрагментация... А она еще кому-то нужна?
>Дефрагментация... А она еще кому-то нужна?кагбе да, если есть желание добиться максимальной скорости работы с устройством.
всё понятно, конечно, zfs рулит, ssd рулит, etc.
(потреbлядство же)
>>Дефрагментация... А она еще кому-то нужна?
>
>кагбе да, если есть желание добиться максимальной скорости работы с устройством.Эта проблема где нибудь существует? кроме как на виндавозных FS?
ЕМНИП Ext4/UFS2 такой бяки почти нет, в отличие от...
безусловно, даже если один кластер с краю блина, а другой в самой жопе, то фрагментации нет, потому что её не может быть, потому что ext4/ufs2/zfs/lyalix/rulez/backtoschool
>безусловно, даже если один кластер с краю блина, а другой в самой
>жопе, то фрагментации нет, потому что её не может быть, потому
>что ext4/ufs2/zfs/lyalix/rulez/backtoschoolа если он еще и на другом диске, вообще лучше сразу застрелиться, иначе как же мы на рейде без дефрагментации то жить будем
>мы на рейдеказалось бы, при чем здесь zfs с дедупликацией
>>мы на рейде
>
>казалось бы, при чем здесь zfs с дедупликациейkeywords
zpool types , raidz , raidz2
>потому что её не может быть, потому что ext4/ufs2/zfs/lyalix/rulez/backtoschoolНет не поэтому, но Ваш красноглазый задор меня развесилил. Вы уж хотя бы матчасть подучите Робачевского почитайте, глядишь знаний прибавиться, а задора анонимного поуменьшится. :-D))
Везде существует. Просто нормальные ФС не склонны создавать ее на пустом месте, в отличие от.
>Эта проблема где нибудь существует? кроме как на виндавозных FS?
>ЕМНИП Ext4/UFS2 такой бяки почти нет, в отличие от...Почти нет - да, но всегда может найтись какойнить граничный случай... я вот например сумел достичь удаления 1 файла на XFS в течении аж 30 секунд и не очень быстрого чтения оного ;).Хотя XFS борется с фрагментацией очень сильно и загнать его в такое состояние можно только весьма специфичными действиями. Остальным тоже можно поднасрать если задаться целью. В реальной жизни конечно засрать том с такими ФС нелегко но - при должных усилиях все-таки возможно несколько просадить.
>>Эта проблема где нибудь существует? кроме как на виндавозных FS?
>>ЕМНИП Ext4/UFS2 такой бяки почти нет, в отличие от...
>
>Почти нет - да, но всегда может найтись какойнить граничный случай... я
>вот например сумел достичь удаления 1 файла на XFS в течении
>аж 30 секунд и не очень быстрого чтения оного ;).Хотя XFS
>борется с фрагментацией очень сильно и загнать его в такое состояние
>можно только весьма специфичными действиями. Остальным тоже можно поднасрать если задаться
>целью. В реальной жизни конечно засрать том с такими ФС нелегко
>но - при должных усилиях все-таки возможно несколько просадить.Насрать, извините, можно везде, но когда при записи 1000 1Гб файлов фрагментация 98%, то это, ещё раз извините, жопа, на фряхе в UFS2 при такой же записи фрагментация 0,2%, на ZFS и того нет. :)
Откуда виндовозный подход и кто вам таки сказал, что фрагментация повышает скорость работы с диском?
>Откуда виндовозный подходстарайтесь реже посещать лор.
>кто вам таки сказал, что фрагментация повышает скорость работы с диском?
логика и здравый смысл.
Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают. Если только при мощном потоковом чтении. Но это не значит, что они не страдают вовсе. И относится это ко ВСЕМ файловым системам без исключений.
>Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают. Если
>только при мощном потоковом чтении. Но это не значит, что они
>не страдают вовсе. И относится это ко ВСЕМ файловым системам без
>исключений.Что за деревья такие? Где можно почитать?
>Что за деревья такие? Где можно почитать?b-дерево. учебник по программированию для первого-второго курса
>Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают. Если
>только при мощном потоковом чтении. Но это не значит, что они
>не страдают вовсе. И относится это ко ВСЕМ файловым системам без
>исключений.Поясните, как Б-деревья помогают избежать фрагментации?
>Поясните, как Б-деревья помогают избежать фрагментации?А никак сами по себе не помогают, ха-ха-ха :))). Чуваки козыряют терминами без включения головного мозга. Более того - CoW-based дизайны еще и сами по себе достаточно склонны к фрагментации. Ну или как кто-то себе представляет всякие там снапшоты без фрагментации, интересно?Собссно CoW-механика подразумевает некую фрагментацию :P
>Все ФС основанные на деревьях Бэйэра от фрагментации сильно не страдают.Позорище космофлота! А вы сможете рассказать почтенной публике как вы представляете логику работы CoW без фрагментации? Да, я более менее въехал как эта красивая и эффективная идея работает ... и с удовольствием вас послушаю, как же там обойтись без фрагментаци, когда собссно копируемый в новое место блок по определению будет неким фрагментом :). Да, когда-то потом возможно выполнить слияние-дефрагментацию и прочая, но сие как раз будет отдельным явным действом.
Мне страшно от слов "менее надежный". Как можно обойтись без точной проверки блоков? Если у нас вдруг окажутся разные данные с одинаковым хэшем то полный пипец будет
А сч его у вас они одинаковые будут?
Ну вот если размер блока 4кбайта, а хэш 256 байт. Сколько блоков удастся однозначно идентифицировать?
>Ну вот если размер блока 4кбайта, а хэш 256 байт. Сколько блоков
>удастся однозначно идентифицировать?Ну возьмите все свои разделы, сбейте хеши и размер всех файлов в БД, поищите совпадающие, сравните по содержимому. Когда найдёте, тогда будет суть флейм. Хотя и так никто трезвый включать эту опцию на /tmp не додумается.
>>Ну вот если размер блока 4кбайта, а хэш 256 байт. Сколько блоков
>>удастся однозначно идентифицировать?
>
>Ну возьмите все свои разделы, сбейте хеши и размер всех файлов в
>БД, поищите совпадающие, сравните по содержимому. Когда найдёте, тогда будет суть
>флейм. Хотя и так никто трезвый включать эту опцию на /tmp
>не додумается.для ценнейших данных там кстати еще и режим verify есть
просто данные для вас не ценны
md5 от IP сильно ускоряет работу многих приложений, но, вот новость то, не уникально это значение, пока поймали за хвост проблему сошло 7 потов. Так же будет если после совпадения Хеша не проверять данные на взаимное совпадение.
>просто данные для вас не ценны
>md5 от IP сильно ускоряет работу многих приложений, но,
>вот новость то, не уникально это значение, пока поймали за
>хвост проблему сошло 7 потов. Так же
>будет если после совпадения Хеша не проверять данные на
>взаимное совпадение.ну так хочешь проверять содержимое, проверяй, есть же эта опция
>Ну вот если размер блока 4кбайта, а хэш 256 байт.
> Сколько блоков удастся однозначно идентифицировать?64 Эксабайт.
Там процент вероятности коллизии имеет значение с 256 нулями, т.е. пока солнце не погаснет надежности хватит. С дргой стороны для контроля целостности теже самые хэши используются и никто не застрахован от сбоя памяти в сочетании с коллизией в ECC.
Тоесть появится некоторый файл такой же длинны, с таким же хешем? К тому же вопрос ставился не про замену SHA256 а про вторичный хеш.
>Тоесть появится некоторый файл такой же длинны, с таким же хешем? К
>тому же вопрос ставился не про замену SHA256 а про вторичный
>хеш.Почему файл? Блок. А блоки все одинаковой длины, не?
Если включено сжатие - разной.
дефрагме... что простите?
А почему скорость должна упасть? Там хеши вычисляются, поиск по хешам милое дело, это вам не обход дерева каталогов с сравнением размера с последующим сравнением содержимого, как в винде все эти чистилки/удалялки копий делают.
Ну это один обход. А тут при каждой записи вычисление хэша каждого блока + поиск + и тд. При перезаписи блока так ещё и ссылки отчищать. Архивная така ФС выходит.
>Ну это один обход. А тут при каждой записи вычисление хэша каждого
>блока + поиск + и тд. При перезаписи блока так ещё
>и ссылки отчищать. Архивная така ФС выходит.Нет, ну как бы ZFS поддерживает архивацию, но речь не о том. Допустим поиск дубликатов будет делать scrub или другая сервисная фича, это ещё предстоит устаканить. Тоесть создав файл предполагается же, что он ещё 33 раза поменяется. Другой вопрос это "упаковать", в порядке сервисного обслуживания.
>Нет, ну как бы ZFS поддерживает архивацию, но речь не о том. Допустим поиск дубликатов будет делать scrub или другая сервисная фича, это ещё предстоит устаканить. Тоесть создав файл предполагается же, что он ещё 33 раза поменяется. Другой вопрос это "упаковать", в порядке сервисного обслуживания.во первых не файл, а блок
во вторых в блоге явно сказано дедупликация происходит сразу же
в третьих чексум блока вычисляется всегда, даже без дедупликации, с ней дополнительно появится только операция поиска в существующих хэшах
что в свою очередь ест память для них, но пока таблица влезает в память практически не сказывается на производительности и дает небольшое замедление при невлезающей в память таблицечитайте первоисточники
>во первых не файл, а блок
>во вторых в блоге явно сказано дедупликация происходит сразу же
>в третьих чексум блока вычисляется всегда, даже без дедупликации, с ней дополнительно
>появится только операция поиска в существующих хэшах
>что в свою очередь ест память для них, но пока таблица влезает
>в память практически не сказывается на производительности и дает небольшое замедление
>при невлезающей в память таблице
>
>читайте первоисточникиПеречитал. Это я затупил, там просто обзор есть, мол "Data can be deduplicated at the level of files, blocks, or bytes".
Что в принципе не так и важно, размер блока вроде как превышает среднестатистический файл (документ, конфиг, исходник, многие утилиты и т.п.)
Интереснее было бы посмотреть на цифры, сколько памяти съест под себя хеш 100 000
блоков к примеру, сколько они при этом "накроют" места. Это позволит более чётко представить, надо оно или нет.
>в память практически не сказывается на производительности и дает небольшое замедление
>при невлезающей в память таблице
>видел, когда ZFS ооочень тормозила, когда системе памяти не хватало.
но это исключительная ситуация - файлов на ФС было создано чрезвычайно много и они постоянно создавались/модифицировались.
>
>>в память практически не сказывается на производительности и дает небольшое замедление
>>при невлезающей в память таблице
>>
>
>видел, когда ZFS ооочень тормозила, когда системе памяти не хватало.
>но это исключительная ситуация - файлов на ФС было создано чрезвычайно много
>и они постоянно создавались/модифицировались.Можете описать, как вы добились такой нагрузки?
вкратце - когда кол-во файлов приближалось к 100 000 000 (сто млн) - ZFS начинал заметно (даже глазу) тормозить, к примеру, на команде
ls -lрешило проблему простое увеличение памяти на сервере - с 8 Г до 16.
всё это дело наблюдалось прошлым летом.
сейчас, возможно, ситуация изменилась.
>видел, когда ZFS ооочень тормозила, когда системе памяти не хватало.Врете. ARC работает независимо от остального VM, поэтому скорее будет паника kmem_too_small, чем zfs будет не хватать памяти. Сейчас сделали backpressure vm на arc, так что arc будет ужиматься если памяти будет не хватать, но все равно даже при arc_max=30M ZFS работает с замечательной скоростью.
> чем zfs будет не хватать памяти.думаю, что "памяти" хватало - никакой паники.
только не вся служебная информация о ФС не могла поместиться в ОП в один момент времени
>>Допустим поиск дубликатов будет делать scrub или другая сервисная фича, это ещё предстоит устаканитьТогда смысл несколько теряется. При удалении/изменении захэшированного файла, всё равно что произойдёт? Делать ремап блоков файла придется. Т.Е получается то-же разархивирование. Каждый раз прогонять распакованный файл и переколбашивать изменнёные блоки - не очень правильное решение.
>>Другой вопрос это "упаковать", в порядке сервисного обслуживания.
Вот и я говорю для архивов - неплохая фишка. Особенно для документных. Или выставлять атрибуты для файла отдельные - "сжимаемый" или фасовать по изменению. Получается "псевдоархив" с большой скоростью доступа.
ИМХО это новшество чем-то напоминает файловую систему venti в Plan 9.
Вставка хардлинка на блок другого файла это фактически фрагментация. При хорошей "оптимизации" пространства скорость чтения должна ощутимо упасть.
>Вставка хардлинка на блок другого файла это фактически фрагментация. При хорошей "оптимизации"
>пространства скорость чтения должна ощутимо упасть.А 33 копии одного и того же файла в разных частях жёсткого диска, это лучше смотрится по части фрагментации?
Им необязательно быть фрагментированными. Все 33 вполне могут быть записаны на поверхности диска непрерывно. А вот если у вас такая помойка, что вы 33 одинаковых файла храните, то спасти место вам никакая ZFS не поможет.
уважаемый, при чем здесь помойка? пример - на сервере несколько десятков человек работают с одним репозиторием какой-нибудь VCS
Если бы у тебя было хоть какое образование то ты бы знал о третьем начале ...
Классический размен скорости на размер. Причём пока не понятно 1:1 или всё же выгодали.
>Если бы у тебя было хоть какое образованиеОх вау.
>то ты бы знал о третьем начале ...
Это что-то из твоей религии?
Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да и сколько там можно сэкономить, дупликатов не так много, да и при текущей цене $/Tb.
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да
>и сколько там можно сэкономить, дупликатов не так много, да и
>при текущей цене $/Tb.А что не так со свободным местом на диске и его калькуляцией? Производительность останется в рамках. Если у вас дубликатов нет и данных для которых эта ФС нужна, может и писать не стоило? Владельцам файлообменников очень пригодится например.
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да
>и сколько там можно сэкономить, дупликатов не так много, да и
>при текущей цене $/Tb.однако это не только место, это и плюс в производительности записи, за счет меньшего числа операций и плюс меньшее использовании памяти приложениями за счет шареных блоков в открытых файлах
>это и плюс в производительности записи, за счет меньшего числа операцийНеверно. Операций будет больше. Потому что COW.
>и плюс меньшее использовании памяти приложениями за счет шареных блоков в открытых файлахНеверно. Никак не повлияет. Для отображения файла в память, ее нужно выделить все равно столько же. А вот процесс чтения будет несколько иным, но он скрыт драйвером ФС.
>>это и плюс в производительности записи, за счет меньшего числа операций
>
>Неверно. Операций будет больше. Потому что COW.
>>и плюс меньшее использовании памяти приложениями за счет шареных блоков в открытых файлах
>
>Неверно. Никак не повлияет. Для отображения файла в память, ее нужно выделить
>все равно столько же. А вот процесс чтения будет несколько иным,
>но он скрыт драйвером ФС.я рад что есть люди знающие системы лучше разработчиков :)
It all depends on your data.
If your data doesn't contain any duplicates, enabling dedup will add overhead (a more CPU-intensive checksum and on-disk dedup table entries) without providing any benefit. If your data does contain duplicates, enabling dedup will both save space and increase performance. The space savings are obvious; the performance improvement is due to the elimination of disk writes when storing duplicate data, plus the reduced memory footprint due to many applications sharing the same pages of memory.
>the performance improvement is due to the elimination of disk writes when storing duplicate dataАга. А когда у одного файла та повторяющаяся часть поменялась, нужно это отследить и выделить дополнительный блок, в который записать изменения.
>plus the reduced memory footprint due to many applications sharing the same pages of memory.Слепление страниц ядро Линукс умеет само.
>>the performance improvement is due to the elimination of disk writes when storing duplicate data
>
>Ага. А когда у одного файла та повторяющаяся часть поменялась, нужно это
>отследить и выделить дополнительный блок, в который записать изменения.если поменялась, запись нового блока идет на общих условиях, что меняем мы этот блок, что новый записываем
отличаются условия для неизменных блоков
>дупликатов не так многоДа нет, на уровне блоков наверняка дубликатов достаточно. Такие вещи как заголовки исполняемых файлов (да и других форматов) ИМХО.
>при текущей цене $/Tb.А это гораздо более существенно. Экономить сотню мегабайт при ее цене в пару баксов путем усложнения ФС (а значит и ее надежности) это как-то неразумно.
>А это гораздо более существенно. Экономить сотню мегабайт при ее цене в
>пару баксов путем усложнения ФС (а значит и ее надежности) это
>как-то неразумно.а сильно от самих данных будет зависеть, на некоторых одни минусы получаем
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного места на диске.. Да
>и сколько там можно сэкономить, дупликатов не так много, да и
>при текущей цене $/Tb.Как-то действительно странно. Если дуБликатов мало, нафига оно надо, если дубликатов много, увеличивается вероятность коллизии.
>Как-то действительно странно. Если дуБликатов мало, нафига оно надо, если дубликатов много,
>увеличивается вероятность коллизии.почитайте про свойства крипто-хеш-функций.
>Сомнительная полезность. В плане производительности, проблемы калькуляции свободного >места на диске.. Да и сколько там можно сэкономить, дупликатов не так много, да и при >текущей цене $/Tb.А на SAS, SAN или даже когда место на RAID заканчивается, и его надо расширять не простым добавлением винтов?
>Для систем, на которых не достаточно проверки по хэшу SHA256, предусмотрен режим повышенной надежности, при котором производится дополнительное полное сравнение блоков данных при совпадении хэша.Круто, то есть, по сути, будут две контрольные суммы (два хэша) - SHA256 и ещё один?
>Круто, то есть, по сути, будут две контрольные суммы (два хэша) -
>SHA256 и ещё один?Ну да, и дополнительная проверка блока на "совпадение". Всё опционально, как и сама фича.
Интересно, к выходу 8.0-RELEASE фича будет доступна?
>>Круто, то есть, по сути, будут две контрольные суммы (два хэша) -
>>SHA256 и ещё один?
>
>Ну да, и дополнительная проверка блока на "совпадение". Всё опционально, как и
>сама фича.Охренеть. Скоро контрольные суммы будут занимать столько же, сколько и сами данные. Тогда можно будет просто заменить их копией данных и проблем с коллизиями не будет.
Будут. Прийдёт злобный аноним, скажет что копия неверная, потому что ему это марсиане сказали, хотя обосновать он это фактами и не может, сотрёт обе записи и вообще нихрена не будет, одни только коллизии в анонимном вакууме
http://en.wikipedia.org/wiki/SHA256Algorithm 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
Похоже уже все лоровцы сюда перебрались. "Фключить моск" никому идея не приходит. Пишут что попало без знания предмета.О вероятности коллизий на пространстве 2^64 для SHA256 алгоритма можно почитать тут: http://www.springerlink.com/content/t1087808x7506841/
Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.> Круто, то есть, по сути, будут две контрольные суммы (два хэша) - SHA256 и ещё один?
Для сравнения блоков по хешу используется тот-же самый хеш, что и для проверки целостности блока. Сравнение блоков на совпадение про "повышеных запросах надёжности", происходит только однажды про создании ссылки !
> Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.Когда-то Intel в Пентиумах допустила ошибку в делении и посчитала её маловероятной. Потом ей пришлось менять все дефектные процессоры за её счёт.
Почитайте что-нибудь про то, как организовывают транзакции: там не смотрят на вероятность неправильного срабатывания, а доказывают правильность работы алгоритма как математики доказывают теоремы.
>Если говорить о 4к,8к,16к,256к блоках, то можно просто игнорировать вероятность коллизии.
>Хм... Вероятность коллизии, получается, стремится к нулю. Ну тогда алгоритм восстановления блока по хешу с вероятностью, стремящейся к 100% - в студию... Это ж какой архиватор получается. Ресурсоемкость алгоритма не интересует.
Ну а ежели тупо посчитать... Длина блока, скажем, 512 байт (1 сектор) = 2^4096. Длина хеша - 256 бит. Итого получаем секторов с одинаковым хешем 2^(4096-256). Понятно, что различных значений хеша меньше, чем секторов на диске, но тем не менее...
вот весело будет если блок сдохнет при такой системе я потеряю все 33 файла а по старинке только один.
>вот весело будет если блок сдохнет при такой системе я потеряю все
>33 файла а по старинке только один.При активной записи на жёсткий диск однотипных данных вы потеряете жёсткий диск раньше, чем при такой системе работы. Или на всём винте вам нужен только один этот файл (кстати, а почему блок сдохнет, циклов перезаписи в него то мы не повторяем? Т.е. это диагноз - винту кранты). И важные данные принято зеркалить, а ещё лучше архивировать куда-нибудь подальше, а то вдруг пожар, а паранойя спать не даёт.
К тому же режим опциональный. Т.е. для вас он будет выключен by default - не бойтесь за свои 33 копии.
В ZFS поддерживаются RAID5/6 конфигурации, при последнем теряйте хоть 2 блока , хоть 2 диска целиком, - данные не будут утеряны.
>В ZFS поддерживаются RAID5/6 конфигурации, при последнем теряйте хоть 2 блока
>, хоть 2 диска целиком, - данные не будут утеряны.Угу, тока называются они RAID-Z1, RAID-Z2. Да, еще и RAID-Z3 есть ;-)
Пример реального применения:
1) вы занимаетесь монтажом видео. Периодически делая копии полученных результатов, чтобы позже иметь возможность откатить изменения. Для такого случая экономия может быть достаточно весомой.
2) все ваши пользователи работают под терминалками внутри одного компьютера с набором похожих данных. Тут тоже возможен выйгрыш.
3) Внутри многих файлов можно обнаружить целые массивы состоящие из символов с кодом 0. Вероятно и тут можно получить выйгрыш. Такого рода крупные разряженные файлы будут получаться достаточно маленькими.
1) лучше решать с помощью snapshot's, уже существующих в zfs.
Не факт. В каталогах структурировать информацию намного легче. Для пользователя точно.
>Не факт. В каталогах структурировать информацию намного легче. Для пользователя точно.ln -s .zfs/snapshot/XXX MyCoolDir, не?
Чушь, это совершенно разные фичи.Вообще вероятность совпадения информации на блоках будет различаться от задач которые решаются. Это очевидно. Но статистически вопрос совершенно неосвещённый :)
> Внутри многих файлов можно обнаружить целые массивы состоящие из символов с кодом 0. Вероятно и тут можно получить выйгрыш.Обработка таких случаев присутствовала в UFS изначально.
Эм, а что, если по умолчанию используется чексуммы fletcher4, а в dedup sha256, будут считаться сразу две чексуммы?
>Эм, а что, если по умолчанию используется чексуммы fletcher4, а в dedup
>sha256, будут считаться сразу две чексуммы?хм, хороший вопрос, похоже да
разве что и для дедупликации включен режим fletcher4,verify
кстати по этому поводу в блоге "On systems with a very high data ingest rate of largely duplicate data, this may provide better overall performance than a secure hash without collision verification. "
Красиво, конечно, расписано для сферических данных с дубликатами в вакууме, но хочется конкретных цифр, например, для VPS-хостинга: экономия такая, скорости чтения/записи стали такие и такие, потребовалось доставить X Гб оперативки/ не потребовалось, эти же параметры через месяц работы.ЗЫ: ну не верю я, что алгоритм записи с созданием хэша для каждого блока и поиска этого хеша в большой хэш-таблице сопоставим по скорости и ресурсоемкости с алгоритмом записи без этих наворотов.
Чего-то я не совсем понял, видать и в самом деле просто туплю.
В новости "...Наиболее заметный эффект от технологии исключения дубликатов можно наблюдать при организации резервного копирования... В таких системах может быть достигнута экономия дискового пространства в разы...". Разве смысл резервного копирования не заключается еще и в том, что куски данных избыточно дублируются (физически), чтобы если сдохнет один блок, данные можно было взять в другом месте? А так все "ссылки" ведут на один блок, он сдох - и сдохли все 15 "ссылок" на этот блок из разных мест файловой системы
особенно если есть множество одинаковых блоков - заполненных нулями и т.п. Тогда ссылок на этот блок будет тысячи
>особенно если есть множество одинаковых блоков - заполненных нулями и т.п. Тогда
>ссылок на этот блок будет тысячиНу как бы, вы ежедневно боитесь того что ваш винт помрёт, а из сервера пойдёт дым. Это вопрос не к ФС, а к тому, где вы покупаете железо. Я же например боюсь что моя доблесная бухалтерия положив очередную сагу о инвентаризации на клавиатуру превратит базу в нечто хаотичное. Или например попадётся добрый вирь, который попытается зашифровать всё до чего дотянется, или просто какой-нибудь умник (царство ему небесное) на шаре попытается удалить всё. В общем не падения железа, а именно нарушения данных. При этом данные как правило не изменяются, а дописываются, дописываются и ещё раз дописываются.
А по железу вон, выше читайте, RAIDZ в помощь.
> Ну как бы, вы ежедневно боитесь того что ваш винт помрёт, а из сервера пойдёт дым. Это вопрос не к ФС, а к тому, где вы покупаете железо.молодец, профессионализм не скроешь )
google dedupditto
Меня вот что интересует.
Вот ZFS обеспечивает дедупликацию на уровне ФС, Оракл на уровне БД, сторэджи (типа Hitachi) вообще чуть ли не на уровне контроллеров. Кстати, сжатия это тоже касается (ну модно сейчас дедуплицировать и сжимать).
Внимание, вопрос: а насколько эффективно будет всё ЭТО работать и сколько ресурсов пожирать в реальной системе? Зачем мне три(!!!) технологии дедкпликации/сжатия на одном несчастном куске данных? Это ведь какая мука для инженера выбрать)
>Вот ZFS обеспечивает дедупликацию на уровне ФС, Оракл на уровне БД, сторэджи
>(типа Hitachi) вообще чуть ли не на уровне контроллеров.Нормальные БД типа SyBase и Oracle позволяют хранить базу на RAW разделе. Что в принципе снижает количество прокладок вдвое.
Не, я не про то (быстродействие баз на raw - отдельная оччччень спорная тема).
Я про именно сжатие (oracle грозит в 30 раз, hitachi в 24, symantec и emc не помню). Смысл в том, что эти механизмы уже реализуются на уровне железа (снизу) и софта (сверху). Теперь эта фича есть в ФС (посередине). Так вот резонный вопрос: а насколько оно всё надо? Особенно учитывая тот факт, что за эти опции тот же Оракл немалые деньги просит. Короче, форониксу задачка не из простых...
Ну если у вас все это (железо, поддерживающее сжатие) есть, то конечно надо где-то отключить. Но ведь у кого-то (сюрприз-сюрприз) может такого не оказаться.
Что-то мне подсказывает, что очень-очень скоро сюрпризом станет наличие проблем с тройной (в лучшем случае) "оптимизацией" хранения данных - вряд ли вендоры будут разбираться в каком окружении будет соседствовать их железо/софт. Кстати, очень любопытно как отнесётся к этой разработке Oracle - им ведь нафик не нужные такие замечательные, но бесплатные фичи.
>как отнесётся к этой разработке Oracle - им ведь нафик не
>нужные такие замечательные, но бесплатные фичи.Это проблемы оракла, что оно бесплатно и замечательно. Пусть сделает лучше и народ подумает, авось стоит заплатить.
>Это проблемы оракла, что оно бесплатно и замечательно. Пусть сделает лучше и
>народ подумает, авось стоит заплатить.А вот в том-то и проблема, что оракл УЖЕ продаёт СВОИ опции БД, сравнимые с возможностями opensource zfs (те же дедупликация/компрессия). И вот тут у Ларри и Co может возникнуть вполне предсказуемое меркантильное желание воткнуть бревно в колёса идей разработчиков zfs (про brtfs традиционно молчим). А вот это уже печально, ибо при всём пафосе никакого комьюнити не хватит довести zfs до ранга популярной фс. А жаль.
Замечательно. Мало того, что ZFS даже не пытается выделять непрерывные куски места под sparse файлы, т.е. файл, скачанный торрентом (где куски приходят черти в каком порядке, и в таком же ложатся на диск, судя по количеству seek'ов при чтении) фрагментирован просто неимоверно, так это теперь еще и его копированием не вылечишь. Way to go.Алсо умиляют идиоты, которые говорят что ZFS не подвержена фрагментации.
Фигассе, вы каждый фильм (которые в последнее время делают с таким сюжетом, что не факт что досмотришь, не говоря о том чтобы пересматривать и сохранять) ещё и копируете на отдельное, сугубо свободное и выделенное для него место? Для таких как вы - опция выключена by default.
>Фигассе, вы каждый фильм (которые в последнее время делают с таким сюжетом,
>что не факт что досмотришь, не говоря о том чтобы пересматривать
>и сохранять) ещё и копируете на отдельное, сугубо свободное и выделенное
>для него место? Для таких как вы - опция выключена by
>default.Нет, это делает торрент клиент. Фракментированный кусок дерьма, разумеется, удаляется.
> ZFS даже не пытается выделять непрерывные куски места под sparse файлыоткуда дровишки? и какой толк в sparse файлах, если место под них выделяется? отключи в своем torrent-клиенте использование sparse файлов тогда.
>Алсо умиляют идиоты, которые говорят что ZFS не подвержена фрагментации.
фрагментация не влияет на скорость SSD дисков. А дефрагметировать ZFS можно при помощи resilver'инга.
>откуда дровишки? и какой толк в sparse файлах, если место под них
>выделяется? отключи в своем torrent-клиенте использование sparse файлов тогда.Место можно выделять, а занимать только если писать больше некуда, знаете ли. Использование sparse файлов отлючить это кшна выход, ради этого надо было ZFS ставить. Только вот мне как-то не улыбается забивание 30гигов нулями при старте торрента, даже если мне их него нужен один 10kb файл. Кроме того, для всех торрентов, которые скачаны на десяток процентов и стоят на паузе, у меня на качающей машинке банально не хватит места.
>фрагментация не влияет на скорость SSD дисков. А дефрагметировать ZFS можно при
>помощи resilver'инга.Особенно на jbod, ага. Да и на raidz это сделано через огромную жопу.
> для всех торрентов, которые скачаны на десяток процентов и стоят на паузе, у меня на качающей машинке банально не хватит места.с dedup=on блоки с нулями не будут кушать места как раньше ;)
поэтому sparse-файлы более не нужны> Особенно на jbod, ага.
нету в ZFS jbod'а. Пул из двух и более диском - это stripe (raid0). Кроме фрагментации там проблемой еще будет self-healing из-за отсутствия репликации (окромя copies).
>с dedup=on блоки с нулями не будут кушать места как раньше ;)
>поэтому sparse-файлы более не нужныОстается только крайне забавный вопрос: в насколько же большую задницу попадет от фрагментации после этого ваша ФС из-за тысяч и тысяч небольших дозаписей блоков, которые по мере скачки торента постепенно, медленно и по садистски *перестанут* быть дупами и стало быть их *придется* раздуплять обратно в отдельные блоки. Один хрен нивелировав ваши потуги экономии места. А вот алгоритмам аллокации все это подгадит очень сильно и мне так кажется что вам не понравится то что вы получите в результате. Если кто храбрый - может проверить, только если у вас том в хлам зафрагментируется - я тут не виноват, это вы все сами, etc :-P. Мой прогноз - если не дай боже скачка будет медленной а объем файлов заметно превысит кэш, скорее всего на томе будет твориться в итоге "полный пэ".
Для начала будет дописываться текущий блок, а потом уже, по мере необходимости, создаваться новый. В общем фрагментация будет такая же, как сейчас или меньше (за счёт того что некоторые блоки уже есть на винте и их сдедупили). ИМХО
>Для начала будет дописываться текущий блок, а потом уже, по мере необходимости,
>создаваться новый. В общем фрагментация будет такая же, как сейчас или
>меньше (за счёт того что некоторые блоки уже есть на винте
>и их сдедупили). ИМХОМеньше? Даже в самом хорошем случае (т.е. все содержимое файла лежит более-менее последовательно), на дедупнутых блоках головы диска придется сгонять куда-то в задницу чтобы достать эти дедупнутые блоки, собственно - чудес не бывает. Т.е. степень фрагментации будет чуть больше. В сильно вермишельных случаях - вот там вопрос интересный. По идее что так что этак будет опа, где больше и где меньше вопрос интересный, скорее всего в обоих случаях вам хватит чтобы проникнуться :). Сбой в логике у вас в том месте что блоки конечно есть и их сдедупили, но вот только для их прочтения придется сделать перемещение голов куда-то сильно в сторону. Единственный вариант когда вы можете быть правы - много одинаковых блоков и кэш удержал нужный блок, так что диск мучать не пришлось. Но это не про торенты...
>[оверквотинг удален]
>чтобы достать эти дедупнутые блоки, собственно - чудес не бывает. Т.е.
>степень фрагментации будет чуть больше. В сильно вермишельных случаях - вот
>там вопрос интересный. По идее что так что этак будет опа,
>где больше и где меньше вопрос интересный, скорее всего в обоих
>случаях вам хватит чтобы проникнуться :). Сбой в логике у вас
>в том месте что блоки конечно есть и их сдедупили, но
>вот только для их прочтения придется сделать перемещение голов куда-то сильно
>в сторону. Единственный вариант когда вы можете быть правы - много
>одинаковых блоков и кэш удержал нужный блок, так что диск мучать
>не пришлось. Но это не про торенты...вот что странно, вначале человек плачет что плахой zfs не выделяет ровное место под дырки в спарс файлах
потом выясняется, что у него дисков на все торренты все равно не хватитдаа однозначно плохая система, не может автомагически и в диск уложится и файлики не фрагментировать
далее не вижу разницы, выделяется новый блок под дырку или из пула дедуплицированных, работает один и тот-же механизм записи нового блока
Боже мой, вас почитать, DOS ещё жив. Про упреждающее чтение ни слова, про буфера дисков ни слова, про кеширование ни слова. Уже совсем тихо о том, что уже давно у всех помойки на винтах. У меня 300Гб одной только музыки. Вы правда уверены что все 300Гб материализовались в одночасье и не фрагментированы? А теперь сорсы, временные файлы, бинари которые постоянно обновляются, пересобираются, пакеты и куча прочей "мелочёвки". Видео оставим в покое, там достаточно большие файлы, чтобы при ваших идеализированных условиях иметь минимальную фрагментацию.
А главное, назовите мне современную ФС в которой таки есть дефрагментатор.
Чудес не бывает, но зачем дважды писать один и тот же блок данных, если такой уже есть на винте. Вот за счёт уменьшения количества записей в данном случае и будет выигрыш в производительности, а так же снижена нагрузка на винт (что позволит ему ещё и пожить подольше).
Ну и к слову о паранойе. Да, я тоже параноик - у меня ОС, исходники, пакажджи и рабочее файло на одном винте, а архив мультимедии, фот, iso-образов и прочего файла на втором винте. И у обоих винтов AAM снижен до минимума и охлаждаются они нормально. Но это не повод мерять всё устаревшими лет 10 назад стереотипами. Давайте ещё сравним LLF времён DOS с современными сервисными утилитами для низкоуровневого форматирования.
>Боже мой, вас почитать, DOS ещё жив. Про упреждающее чтение ни слова,
>про буфера дисков ни слова, про кеширование ни слова. Уже совсем
>тихо о том, что уже давно у всех помойки на винтах.
>У меня 300Гб одной только музыки. Вы правда уверены что все
>300Гб материализовались в одночасье и не фрагментированы?ну это же очевидно, у них регулярно по расписанию стартует дефраг на их терабайтные массивы, а люди типа спят спокойно))
>Ну и к слову о паранойе. Да, я тоже параноик - у
>меня ОС, исходники, пакажджи и рабочее файло на одном винте, а
>архив мультимедии, фот, iso-образов и прочего файла на втором винте. И
>у обоих винтов AAM снижен до минимума и охлаждаются они нормально.Эм... никакой надёжности. Это не параноя, это идиотизм вроде как. У меня всё ценное лежит на зеркале и бекапится, система на отдельном венике и бекапится, хлам и интернета ещё на одном венике.
>Давайте ещё сравним LLF времён DOS с современными сервисными утилитами для
>низкоуровневого форматирования.Вам сколько лет? Современные винчестеры (это которые вышли за последние 15 лет, хотя может и более старые тоже) не поддерживают LLF ни в каком виде. Только на стенде. LLF был актуален для дисков с разомкнутой системой позиционирования и шаговыми двигателями. Сейчас, когда сервоинформация лежит на диске и система позиционирования замкнута, LLF достаточно выполнить один раз на заводе.
>Эм... никакой надёжности. Это не параноя, это идиотизм вроде как. У меня
>всё ценное лежит на зеркале и бекапится, система на отдельном венике
>и бекапится, хлам и интернета ещё на одном венике.«Automatic Acoustic Management» (AAM) - оперативная регулировка уровня шума, издаваемого накопителем в результате движения головок за счёт уменьшения скорости их перемещения. Тоесть фактически я его ещё тормознул чутка. Тоесть меня устраивает скорость, а вот фрагментация меня мало волнует на данном этапе. Это домашняя машина, на работе музыку и мультимедию гигабайтами не храню, а базы данных поменьше весят ;)
>Вам сколько лет? Современные винчестеры (это которые вышли за последние 15 лет,
>хотя может и более старые тоже) не поддерживают LLF ни в
>каком виде. Только на стенде. LLF был актуален для дисков с
>разомкнутой системой позиционирования и шаговыми двигателями. Сейчас, когда сервоинформация лежит на
>диске и система позиционирования замкнута, LLF достаточно выполнить один раз на
>заводе.Я знаю про LLF, это был сарказм, причём не в вашу сторону. Только чутка вы неправы. Современные винчестеры поддерживают LLF, только это не тот LLF который был 15 (точнее уже наверное 18 или 19) лет назад, в котором всё тупо бомбилось нулями, а свои, более современные варианты. Возьмите сервисные утилиты для винтов и найдёте там пунктик низкоуровневого форматирования.
>Давайте ещё сравним LLF времён DOS с современными сервисными утилитами для
>низкоуровневого форматирования.Разве это не функция самого винчестера? Для IDE по крайней мере так... А действительно сервисные утилиты вполне себе живут и под ДОС, требуя при этом дополнительного железа типа РС-3000.
а без дедупликации каким местом self-healing работает (окромя copies) ?
Вот блин почему так трудно узнать ответ на те вопросы, которые действительно интересны?
Насколько я понял, благодаря тому что sha256 получается уникальным, при отключенном dedup можно делать self-healing через поиск блоков с совпадающим sha256. А вот делает ZFS это или нет непонятно. Нагуглил только что в сложных комбинашках, например в зеркале, она self-healing за счёт копии делает.
Была бы такая пальцатая ФС с самовосстановлением, останется только блекджек прикрутить и гарных девок.
Sha256 in ZFS IS used for self healing if you set it as checksum algorithm.. It is used, instead of fletcher, to check integrity of every block in datasets, not only in RAIDZ. It was like that since creation of ZFS, and now this same checksum field can be used for two purposes, integrity and deduplication.Posted by Bartek Pelc on November 04, 2009 at 08:52 AM PST #
Всё, осталось блекджек и гарных девок. Зачётная ФС
> при отключенном dedup можно делать self-healing через поиск блоков с совпадающим sha256.ЕМНИП, не делает. Но на основе dedup кода, думаю, будет сделать не трудно. Что-то типа dedup=keep, когда reference count'ы увеличиваются, но при повреждении данных в одном идет self-healing за счет оставшихся. Только это будет мало чем отличаться от copies.
Какой dedup? Какое copies? Фиг с ними, это мне уже не интересно.
Хеши совпадают только если данные совпадают. Значит при условии что мы сможем нати второй такой же хеш, мы найдём и такие же данные. Копия это или другой файл, в котором по счастливой случайности совпал блок данных, это уже не важно. Важно то что это можно использовать для self-healing и по их словам это уже есть и вроде должно работать. Вот только как это протестировать подручными средствами, интересно.
> при условии что мы сможем нати второй такой же хеш, мы найдём и такие же данныедо dedup'а кода для поиска случайно совпавших hash'ей в ZFS не было. refcount'ы считались только для подготовленных заранее копий mirror/raidz или copies.
> Вот только как это протестировать подручными средствами, интересно.
zinject(1M)?
>Хеши совпадают только если данные совпадают.Неа. _если_ данные не совпадают, _то_ хеши не совпадают. Обратное неверно, т.к. число различных значений хеша меньше числа различных значений данных.
Хочу архиватор, пакующий 256кб в 256б.
>>Хеши совпадают только если данные совпадают.
>
>Неа. _если_ данные не совпадают, _то_ хеши не совпадают. Обратное неверно, т.к.
>число различных значений хеша меньше числа различных значений данных.
>
>Хочу архиватор, пакующий 256кб в 256б.я бы сказал что если хеши совпадают то данные могут не совпадать (если данные не совпадают то хеши могут совпадать)
я очень сомневаюсь что алгоритм дедупликации тут основан только на сверке хешей, иначе сан с зфс поимели бы разгневанные заказчики, которых поимели их данные
Вы ветку внимательно читали? Про то что коллизий нет читали? Про то что в Sun не ламеры работают догадываетесь? Про то что для параноиков есть отдельные опции второго хеша и сверки данных не догадываетесь? Нет? Тогда надо натравить на вас чихающую хрюшку, это сейчас самое модное заклятие...
>Вы ветку внимательно читали? Про то что коллизий нет читали? Про то
>что в Sun не ламеры работают догадываетесь? Про то что для
>параноиков есть отдельные опции второго хеша и сверки данных не догадываетесь?
>Нет? Тогда надо натравить на вас чихающую хрюшку, это сейчас самое
>модное заклятие...извините, но вы - лох, если считаете что в продакшен будет стоять сервер у которого вероятность потерять 512 любых байт в день ненулевая чисто из-за организации программы, а при сверке хешей коллизии ОБЯЗАТЕЛЬНО БУДУТ (иначе мы получаем мечту человечества об архивации всего и вся в 256 байт (делаем один хеш, от него второй хеш, от оного третий. и пока весь петабайт не свернём в 256 байт))
это как использовать архиватор который толи распакует ваш файл потом толи нет, русская рулетка очень радует товарищей бизнесменов
да и простых юзверей такая перспектива думаю тоже нифига не порадует
Тоесть вы однозначно утверждаете что вы умнее ребят из Sun которые разрабатывают ZFS? Нифиговые у вас понты однако
> с dedup=on блоки с нулями не будут кушать места как раньше ;)
> поэтому sparse-файлы более не нужныАга. Терь для торрентов нельзя будет использовать ZFS вообще, гыгы.
> нету в ZFS jbod'а
Ну страйп, какая разница. Никакого ресильверинга не будет в любом случае.
Иди учи матчасть, а потом перечитай свое сообщение и отредактируюй как следует.
>Иди учи матчасть, а потом перечитай свое сообщение и отредактируюй как следует.Сначала напиши в поле "сообщение", что хотел сказать, потом жми "Отправить", позорище.
значит ли это, что я могу перемещать/копировать файлы между ZFS-датасетами почти мгновенно?
Нет, это значит, что 'cat /dev/dull > $FILE' теперь совсем не ограничен по объёму файла и практически не ограничен по количеству таких %) файлов на диске. :-D
/dev/zero хотели сказать?
>/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 тупит %)
>'cat /dev/dull > $FILE'Что за девайс у вас такой хитрый? Он показывает при этой операции дулю? Или что за ...? :)
не очень понятно можно ли использовать по дефолту быстрый fletcher4, и, если такой блок уже есть, то сверять еще и sha256? или ничем не будет отличаться от verify?
>не очень понятно можно ли использовать по дефолту быстрый fletcher4, и, если
>такой блок уже есть, то сверять еще и sha256? или ничем
>не будет отличаться от verify?Если я правильно понял, то как раз и имелось ввиду что можно использовать fletcher4 для ускорения и второй алгоритм можно прикрутить.