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

тогда уж 'zfs set dedup=on' - оно выключено по умолчанию =)
и не раздел, а pool - это немного разные вещи. хотя если отталкиваться от классических файловых систем - то наверное да.

> > подготовим по известному его хэшу какой-нибудь руткит

Это ещё круче :-)

> С крпитостойким хэшем нереально.

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

>Ынтырпрайз - чревато. Будет очень много охотников за коллизиями.

я опять повторюсь - технология _не новая_. netapp подобное ввёл у себя еще 2 года назад. как-то охотники не появились.

И понабежали анонимные аналитеги которые кроме своей теребайтной помойки с порнухой ничего не видели. Как упоминалось фича эта давно есть у нетапа, и например помогает экономить изрядно места на дорогущих FC дисках. Да она имеет смысл не везде и не всегда. Это не повод кричать о ненужности.
Вывод: нужно, пусть будет. Рад за ЗФС.

>на будущее нужно запомнить, что ненадёжность SHA256 будет означать

Можно просто запомнить, что чем проще - тем надёжнее. В будущем, когда железо будет ещё мощнее и ещё дешевле, это будет ещё актуальнее. А кто стремится в противоположном направлении - тот свои грабли найдёт, даже до взлома sha256.

Наведите порядок на диске, и не храните одинаковые файлы дважды. У меня получилось строго 0.

>Наведите порядок на диске, и не храните одинаковые файлы дважды.

С этими советами - к разработчикам zfs.

А почему бы не проверять блоки побайтно, если совпал хеш? Коллизии тогда не произойдет. Или проверять на совпадение несколько байт из блока. Насколько я понимаю, это на порядки уменьшит вероятность коллизии.

А если проверять блоки побайтно, зачем тогда хеш?

Вы не поняли =) Проверять побайтно, когда хеш совпал, чтобы сделать заключение об идентичности.

Проверять побайтно, когда хеш совпал, чтобы сделать заключение об идентичности.

If you accept the mathematical claim that a secure hash like SHA256 has only a 2^-256 probability of producing the same output given two different inputs, then it is reasonable to assume that when two blocks have the same checksum, they are in fact the same block. You can trust the hash. An enormous amount of the world's commerce operates on this assumption, including your daily credit card transactions. However, if this makes you uneasy, that's OK: ZFS provies a 'verify' option that performs a full comparison of every incoming block with any alleged duplicate to ensure that they really are the same, and ZFS resolves the conflict if not. To enable this variant of dedup, just specify 'verify' instead of 'on':

zfs set dedup=verify tank

Потроллить вдруг захотелось, уж простите. Вот есть freebsd с лицензией, которая позволяет делать что угодно. Т.е. "чистая" свобода, в отличии от "защищённой" свободы gpl. Есть опенсолярис, из которого freebsd "тырит" фишки, т.к. своих сил создавать что либо уже практически не осталось. У соляриса лицензия, насколько я понимаю, скорее что-то параллельное gpl, чем аналог bsd? Так вот, в чём, собственно, профит? Хочешь всякие dtrace и zfs, единую кодовую базу, имеешь аллергию на линукс - ведь есть же соларис от уважаемых сан-ораклов. Зачем, собственно, freebsd при таком раскладе? Вот кроме лицензии ну ничего в голову не приходит, может расскажите?

Кстати, да, OpenSolaris научился hdparm-у или его аналогу (в частности - вырубать Advanced Power Management)? А то все не доходят руки попробовать.

>Зачем, собственно, freebsd при таком раскладе? Вот кроме лицензии ну ничего в голову не приходит, может расскажите?

Ну, они часто ссылаются простоту... Если им не осилить линукс, то куда ж солярку.

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

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

SSD нет, а HDD достаточно подешевели, но очередь SSD не за горами... вспомните динамику цен на dvd

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

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

А я прогнал этот скрипт по директории, где у меня лежат дистрибутивы (в т.ч. в виде исходников), скачанные из интернета, и сборки исходников. И уменьшил размер блока до 4 Кб ($bs=4096). Получилась экономия ~13%, что составило около 9.5 Гб. Немало ведь.

А если бы еще по корню кто прогнал... И с блоками, например, по 2Кб... Только это будет надолго.

Для ядра Linux есть патч, реализующий похожий механизм для поиска дублирующихся страниц оперативной памяти - KSM (см. напр. http://lwn.net/Articles/306642/). Не знаю, вошёл ли он в основное дерево кода ядра или нет. Предполагаемая область применения этого патча примерно такая же, как и обсуждаемой возможности ZFS - компьютеры с большим количеством виртуальных машин.

вмваре даже в домашней версии это умеет

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

расслабься и подумай

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

там же только некоторые модели с кривой фирмварью так валились. мне как то попадался один привод который на одном диске наглухо вис.

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

В крупных многопользовательских файлопомойках. Или на мэйлру каком-нибудь.

И если этот блок накроется, то накроются все подобные файлы.

Круто.

>при размере ФС 4000ТБ получим 1/10^45 в месяц

Ученые подсчитали, что шансы реального существования столь откровенно абсурдного мира равняются одному на миллион.

Однако волшебники подсчитали, что шанс "один на миллион" выпадает в девяти случаях из десяти.

(c) Терри Пратчетт "Мор, ученик Смерти".

И что? Волков бояться - в лес не ходить.

Однако волшебники подсчитали, что шанс «один на миллион» выпадает в девяти случаях из десяти.

«шанс выжить у него 50 на 50, правда шанс на такой шанс всего 2%» (с) голый пистолет

а как же избыточность? энтерпрайз же.

>А я прогнал этот скрипт по директории, где у меня лежат дистрибутивы (в т.ч. в виде исходников) ... Получилась экономия ~13%

Исходники, небось, распакованные?

мне интересно как оно будет себя вести при высокой нагрузке на дисковую подсистему. например N софтин создали M файлов с 0 внутри. ZFS это определила и выделила на все файлы один блок. потом софт начинает работать и рандомно писать в эти файлы.

господа, из-за чего срач-то???

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

вы чего, ребята??

сверка включается опционально + лишнии телодвижения для сверки

>>10^-77 or, in more familiar notation, >>0.00000000000000000000000000000000000000000000000000000000000000000000>>00000 0001.
спасибо, кэп!

энтропия/фрагментация в мозгах человечества увеличивается...
Пейсатели наверное НортонДиск^Wtestdiskом файлы не восстанавливали и многолетние архивы у них никогда не сыпались и дикетами они никогда не пользовались.
Людям индирекшенов не хватает, инодов не хватает. Совсем о восстановлении данных не думают...
Увеличение дискового пространства подчиняется закону Мура, в отличие от скорости IO, т.е. при их расхождении как сейчас - экономить на дисковом пространстве за счёт надёжности данных - идиотизм. Наоборот - интернет надёжен из-за избыточности информации. Только не говорите что мне мужны рейды или бекап - они и так есть.
Проблема - в долговременных архивах которые хранятся десятилетиями и в которых всё равно накапливаются сбои со временем. И которые перепроверять нет возможности. А сбои могут быть на обоих копиях. К ним можно относиться - как к дискетам. После десятков лет - обязательно будут битые блоки или потерянные суперблоки. Достаньте 2-3 дискеты с одной и той же информацией года с 92-го и попробуйте сегодня восстановить содержимое.
Пока я могу восстановить битую дату - такими тулами как testdisk, или написав программку на ц - если данные очень важны.

Пока я могу, сбрасывая архив, сделать доп. копию очень важных файлов и знаю, что физически эти 2 файла находятся в разных блоках. И в случае восстановлении данных после атомной^W дизастера, где даже суперблоки коррапчены - смогу понять - какие блоки заглючили в суперблоках, какие - в файловых блоках, просмотрев редакторами и восстановив тестдиском. И прочитать нужный адрес, телефон, дипломную работу или программу которую я писал 20 лет назад.
Теперь - если уж сглючит - то навсегда (так как будет одна копия) и я не смогу копированием самых главных файлов - делать себе пис оф маинд. Не есть гут. В топку. Останусь на ext3.

для многолетних копий ext3 подойдет еще меньше. откройте для себя hp dataprotector наконец например.

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

Для сокращения темпов роста энтропии есть маза не читать новостей вовсе (и отключить интернеты).

>В ZFS появилась поддержка исключения дубликатов
для многолетних копий ext3 подойдет еще меньше. откройте для себя hp dataprotector наконец например.
>никто не заставляет искать дедупы на многолетних копиях. это опция для рабочих, быстрых и дорогих дисков. а не для ленточке по 5 рублей за пучёк.

Уверены - что ваши дети смогут запустить этот HP Data Protector - на системах, которые будут распространены, скажем, через 20 лет? Что ещё будут такие компании существовать и что совсем невероятно - будут поддерживаться программы и все старые форматы метадаты этих программ?
Сравнение программ и систем, которые были в ходу 20 лет назад и сегодня - говорит об обратном.
И не говорите про ленты. Они не позволяют моментального доступа. Они должны умереть. Вспомним ленты и всякие 100-зип всего-то несколько-летней давности. Только диски имеют смысл.

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

> Для сокращения темпов роста энтропии есть маза не читать новостей вовсе (и отключить интернеты).

есть ещё. Наводить порядок. Показывать на ошибки. Ненужное само отомрёт.

с лентами как раз всё шикарно, там форматы не меняются десятилетиями. и hp data protector слава богу кстате лет 10 уже отпраздновал точно. а вот MFM-ный диск например пожалуй щас прочитать и нечем. по крайней мере я даже не знаю в какой гамазин бежать. в музей?

зачем поддерживать ленты вообще? Я хочу моментальный доступ. Если уже есть архивный сервер он-лайн - то гораздо проще сделать rsync на второй (и третий) клон этого сервера. Если архивный сервер-мастер летит - переключение на 2-й - минута. Ленты не нужны.

>лет 10 уже отпраздновал точно
а гнутые проги и их коды со мной (и моими детьми-внуками-правнуками-итд) будут всегда.

> там же только некоторые модели с кривой фирмварью так валились. мне как то попадался один привод который на одном диске наглухо вис.

Не, там фирмварью дело не поправлялось, проблема аппаратная. Не валились только некоторые модели CD-Rom, из серии "для профессионалов".

>зачем поддерживать ленты вообще? Я хочу моментальный доступ. Если уже есть архивный сервер он-лайн - то гораздо проще сделать rsync на второй (и третий) клон этого сервера. Если архивный сервер-мастер летит - переключение на 2-й - минута. Ленты не нужны.


зачем моментальный доступ к тому что хранится десятками лет? гораздо лучше положить инфу на нечто, выживаемость которого намного выше винтов. или так и будем туда-сюда таскать? да и легкая доступность информации - первый шаг к ее потере т.к. человеческий фактор и rm -rf / никто не отменял.

кстате ваши сервера не поддерживают WORM потому не будут сертифицированы например карающими и проверяющими органами.

>а гнутые проги и их коды со мной (и моими детьми-внуками-правнуками-итд) будут всегда.

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

всё дело в том - насколько важны данные.
Иногда старая дата бесценна (единственные фотки умерших родственников, нужное мыло, старые статьи, адреса итд, в будущем наверное будут целые генотипы итп). Что и когда понадобится - неизвестно. А на чужие облака надеяться - ссыкотно. И часто предиктить что дублировать - тоже невозможно. И чем проще восстановить в будущем - тем ценнее система. иноды по простоте восстановления - вполне устраивают. Гарантирует пис-оф-маинд уже.

>чем проще восстановить в будущем - тем ценнее система

как говорил великий учитель Инь Фу Во: моя главная задача - защитить информацию от меня. от врагов это сделают безопасники.

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

>сверка включается опционально + лишнии телодвижения для сверки Угу. Набрать лишних 4 буквы. Вместо --dedup=on написать --dedup=verify.

А опционально - потому что коллизии маловероятны.

> зачем моментальный доступ к тому что хранится десятками лет? гораздо лучше положить инфу на нечто, выживаемость которого намного выше винтов. или так и будем туда-сюда таскать? да и легкая доступность информации - первый шаг к ее потере т.к. человеческий фактор и rm -rf / никто не отменял.

распыление сил. И надо верить в то - что данные не сломались, т.е. доступаться надо хотя бы иногда.
rsync-нье с 1го уровня на 2ой раз в месяц и со 2го на 3й - раз в год - действует как успокоительное.
Вы готовы записать на ленту - и оставить её внукам? Я например обнаружил, что старые дисководы просто летят не с того ни с сего (видимо конденсаторы сохнут или что-то ещё). Не уверен что лентопротяжный механизм протянет ещё лет 10, тем более 40 (где не только мои внуки, но и я захочу покопаться в дате - при написании мемуаров).

против rm -f есть много уровней. Восстановление тривиально и быстро, в отличие от ленты.

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

не хочу надеятся на вендорлоки. Хочу дату иметь у себя.

> господа, из-за чего срач-то???

> ведь при совпадении хеша он затем проверяет данные побайтово. так же делается поиск в индесированных БД.

Это один из вариантов работы. Если указать verify - будет проверять побайтово, если указать on - не будет, поскольку вариант без проверки выглядит достаточно надёжным (и сейчас является таковым) большинство наверняка выберут его. Но если взломают SHA256...

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

а если и взломают, какие вопросы? допустим есть некий фаел например sshd, который мы хотим инжектнуть. злой хацкер пытается подобрать коллизию на некий блок sshd, в которую можно было бы всунуть сплоет, и наконец, проделав титанический(!) труд, шлёт например письмецо или хитрый http-реквест на желаемый сервер.

дальше идёт облом - поскольку письмецо на сервер пришло _после_ того как был установлен sshd, великая коллизия письмеца заменяется на код sshd. одмин хмыкает и удаляет абрвалг. краснаглазые хакеры пытаются ломать sha512

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

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

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

> как говорил великий учитель Инь Фу Во: моя главная задача - защитить информацию от меня.

многоуровневое rsync-анье - самое надёжное что может быть. Дисциплина периодических бекапов (раз в год - на последний носитель) гарантирует перенесение ошибки только в случае если решено всё снести и это решение не изменено в течение года. Но с лентами у Вас будут как минимум все те-же а скорее - даже большие проблемы. rsync для бекапов + дисциплина - рулят.