NexentaStor Developer Edition 1.0 вышла!

>Ну товарисч анонимус конечно же открыл всем глаза, но он не знал, что в ZFS, ещё со второй версии пула добавили Ditto Blocks для metadata, а в последствии и данных, и того, что это значит, что каждый metada block дублируеться 2 или 3 раза, в зависимости от настроек, заданных Администратором, повреждение 2 или 3 блоков, одновременно, расположенных на разных контролерах и стораджах, просто НЕ РЕАЛЬНО посему гуляйте лесом уважаемый...;)

Ну да, добавили костыль к уже существующему...

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

ZFS self-healing и этот пресловутый raid-z всего лишь маркетинговый ход (а вы повелись), т.к. работает все это заметно хуже обычного raid, т.к. легко позволяет терять данные.

Кстати, раз уж вы так любите это поделие, объясните, зачем дублировать данные, если они и так должны "восстанавливаться" из raid-z в случае ошибок (диска, контроллера, фс и т.п.)? А делается это для того, что raid-z - гавно, а mirror - нет, а т.к. уже все раструбили и отфанфарили, придется поддерживать кривую технологию, пусть хоть с костылями не рассыпается. Впрочем, как всегда в Sun.

> При выходе из строя диска в целом, например при его замене, могут пропасть все копии, поэтому солярис с zfs находится в серьезной зоне риска при выходе всего лишь одного диска из пула, т.к. не известно, куда дублируются блоки.

Для тех кто в танке, читаем документацию на ZFS, там чёрным по белому написано, что блоки ложаться на _СОСЕДНИЕ ДИСКИ_, при возможности _КОНТРОЛЕРЫ_, хватит тупить...;)

> ZFS self-healing и этот пресловутый raid-z всего лишь маркетинговый ход (а вы повелись), т.к. работает все это заметно хуже обычного raid, т.к. легко позволяет терять данные.

Бугага... факты, пожалуйста...;)

> Кстати, раз уж вы так любите это поделие, объясните, зачем дублировать данные, если они и так должны "восстанавливаться" из raid-z в случае ошибок (диска, контроллера, фс и т.п.)? А делается это для того, что raid-z - гавно, а mirror - нет, а т.к. уже все раструбили и отфанфарили, придется поддерживать кривую технологию, пусть хоть с костылями не рассыпается. Впрочем, как всегда в Sun.

Под стулом...:-D:-D:-D Красноглазый фанатег в действии...:-D:-D:-D

> а вот официальная тех поддержка SUN говорит,что ZFS в продакшн нельзя.

Это никого (здесь) не волнует. Клавное пальцЫ и понтЫ.

Недавно наша контора купила комплекс - сан ынтырпрайз + массив от фирмы из 3-х букв на ~ 90 сырых терабайт. Сановцы не сказали что ZFS в продакшн конкретно нельзя, но не советовали.

А что они Вам посоветовали тогда, QFS/SAMFS??:)

>Для тех кто в танке, читаем документацию на ZFS, там чёрным по белому написано, что блоки ложаться на _СОСЕДНИЕ ДИСКИ_, при возможности _КОНТРОЛЕРЫ_, хватит тупить...;)

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

Т.о. ZFS сливает при использовании raid-z.

>> ZFS self-healing и этот пресловутый raid-z всего лишь маркетинговый ход (а вы повелись), т.к. работает все это заметно хуже обычного raid, т.к. легко позволяет терять данные.

>Бугага... факты, пожалуйста...;)

Вам привели пример, когда raid-z рассыпается, с чего вы думаете появилось дублирование метаданных? Теперь представьте, что 2 диска начали сыпаться вместе - один вытащили, на втором пропали _все_ данные, т.к. raid-z не позволяет вытащить данные без метаданных.

>Под стулом...:-D:-D:-D Красноглазый фанатег в действии...:-D:-D:-D

Вот и все ваши аргументы... Слив защщитан.

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

Ох... ещё раз... если контролер один, а диска два, то Вы не зделаете raidz, это раз, второе, если падает один винт, то это нечего не меняет, metadata block-и распложены на других двух винтах, так Вам понятнее??:)

> Вам привели пример, когда raid-z рассыпается, с чего вы думаете появилось дублирование метаданных? Теперь представьте, что 2 диска начали сыпаться вместе - один вытащили, на втором пропали _все_ данные, т.к. raid-z не позволяет вытащить данные без метаданных.

RAIDZ не льзя зделать из двух дисков, минимум из 3-х, как и любой RAID5, далее, если в RAID5 сыпяться 2 из 3 дисков, то Вас нечего не спасёт уже, при занятости массива естественно больше чем на одной диске места...:)

> Вот и все ваши аргументы... Слив защщитан.

Где Ваши аргументы?? Где факты, что были проблемы такие у кого-то?? Где они?? Нет их?? Слив защитан.(C) :-D:-D:-D

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

ti doplpaep tupoi, esli y teba hardware raid est nafiga poverh ewe masterit 4toto programnoe esli na kontrolere sdelat mojno.

i skaji esli y teba raid 1 do na kakoi failovoi sisteme danie ne poheraca esli disk sdohnet? ne podskajesh kakaya iz vozduha infu beret? tolko v raid1 vihod iz stroya diska vle4et poteru infi, tak-kak netu izbito4nosti, vo vseh drugih konfiguraciyah est izbito4nost danih i kakya fs poverh krutica kontroleru fioletovo.

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

У мну тут мысль промелькнула, а Вы случаем не путаете RaidZ-1/2 с Raid-1 mirror, который тоже есть в ZFS, но называеться mirror-ом???;) Вестимо путаете, потому, что RAID-Z - это RAID-5, а посему и строиться он минимум из 3-х дисков, в которых может выйти из строя при такой конфигурации 1, если используеться 4-е диска и RAID-Z/2, то тогда два диска...;)

> Вам привели пример, когда raid-z рассыпается, с чего вы думаете появилось дублирование метаданных?

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

>У мну тут мысль промелькнула, а Вы случаем не путаете RaidZ-1/2 с Raid-1 mirror, который тоже есть в ZFS, но называеться mirror-ом???;) Вестимо путаете, потому, что RAID-Z - это RAID-5, а посему и строиться он минимум из 3-х дисков, в которых может выйти из строя при такой конфигурации 1, если используеться 4-е диска и RAID-Z/2, то тогда два диска...;)

Вы совсем не читаете, что вам пишут. raid-z развалится не из-за того, что диски, на которых лежат данные, вышли из строя, а из-за того, что метаданные пропали. Метаданные могут лежать на двух жисках, если один из них вышел из строя, то малейшая проблема со вторым (испорчены метаданные) ведет к потере данных. Все, никакие 10 дисков в raid5/raid-z при этом не помогут, т.к. потеряна информация о размере erasure block, и raid-z не может восстановиться.

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

Именно из-за этой проблемы с метаданными было создано зеркалирование блоков метаданных, и в довесок зеркалирование блоков данных.

>С того, что, Ditto Block-и используються для повышения общей отказаустойчивости файловой системы, не только в RAID конфигурациях, так же в ZFS можно зделать RAID, без RAID, зделав это в рамках Ditto Block-ов, только для отдельной FS, а не в рамках всего пула...;)

Ответ неверный. Это было добавлено для лечения проблем zfs, а не для повышаения отказоустойчивости. Для повышения отказоустойчивости есть raid/mirror/что угодно на уровне физических устройств. Как вам уже написали, это _не_помогает_ в общем случае в конфигурации с raid-z, хотя согласен, без этого костыля дублирование метаданных весьма полезно, если нет зеркалирования на уровне физического устройства.

Вы вообще тот же аноним или уже следующий??:-\ Как могут просто исчезнуть метаданные или как они могут быть повреждены, а данные не поврежденны при этом??:-\ Хорошо, давайте перейдём от теории к практике, пожалуйста факты того, что у кого-то была такая проблема...:)

>Вы вообще тот же аноним или уже следующий??:-\ Как могут просто исчезнуть метаданные или как они могут быть повреждены, а данные не поврежденны при этом??:-\ Хорошо, давайте перейдём от теории к практике, пожалуйста факты того, что у кого-то была такая проблема...:)

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

Ваше незнание этого говорит о том, что вы понятия не имеете о том, о чем рассуждаете, и очень мало работали с настоящим оборудованием. Зато уже прочли рекламные статьи Sun.

Ещё раз, давайте отойдём от того, с чем я там работал, а Вы всё таки предоставите факты, о том, что действительно у кого-то были проблемы, о которых Вы говорите с ZFS...;)

Кстати, вот вам еще одна новость: в файловых системах, где преобладают маленькие файлы (до 4к), объем метаданных превышает или сравним с объемом данных. Поэтому вероятность попортить метаданные выше вероятности порчи данных. Однако при этом данные будут потеряны, хотя могли бы быть восстановлены (без сохранения имен и т.п. метаинформации).

Если Вы хотите знать, то SUN мой боГ, а я его пророк, а docs.sun.com и opensolaris.com читаю, как библию перед сном, но всё же жду, что Вы от балабольства перейдёте к делу и предоставите всем факты о проблемах ZFS с её реализацией RAID-Z...;)

>Ещё раз, давайте отойдём от того, с чем я там работал, а Вы всё таки предоставите факты, о том, что действительно у кого-то были проблемы, о которых Вы говорите с ZFS...;)

Если мне не верите, почитайте здесь: http://www.linux.com/articles/51237

А вот откуда растут ноги ditto blocks: http://blogs.sun.com/bill/entry/ditto_blocks_the_amazing_tape

"So even if an entire top-level vdev fails (a mirror or RAID-Z stripe), we can still access data", а случиться это может при порче метаданных. Ooops. Обратите внимание на дату - 2006 год.

А вот raidz: http://blogs.sun.com/bonwick/entry/raid_z - 2005 год.

Спасибо, почитаю, фактов порчи данных пока не вижу, что Ditto Block-и добавили во 2-й версии пула я знаю...:)

Почитал первую ссылку, нечего криминального не увидел, в прочем читал по диагонали, что касаеться второй ссылки, то её читал, когда, как раз и вышла вторая версия пула c Ditto Block-ами, то что они с одной стороны добавили redurancy, а с другой исправили упущение, которое не увидили, при проектирование, это не отменяет нечего для меня...:)

Also, unlike other RAID levels, which write all files in the same size stripe regardless of the file size, RAID-Z allows for variable stripe width -- and without correct metadata to tell the filesystem how to reconstruct a file if it is lost, as well as where in the system it is supposed to go, the filesystem would not be able to serve as a backup.

Это я прочёл, для повышения отказаустойчивости данной архитектуры, когда используеться переменная длинна страйпа и были введены Ditto Block-и, что в прочем не отменяет их приимуществ для использования не только в raid-z конфигурациях...:)

>Это я прочёл, для повышения отказаустойчивости данной архитектуры, когда используеться переменная длинна страйпа и были введены Ditto Block-и, что в прочем не отменяет их приимуществ для использования не только в raid-z конфигурациях...:)

А теперь попросите учительницу объяснить, что произойдет, если начали сыпаться жесткие диски (например если blade-сервер недостаточно крепко прикручен или стойка несбалансирована, со временем это произойдет в 100% случаев, что неоднократно наблюдал), и один из них удалили (где был ditto block, возможно неиспорченный), а метаданные на втором осыпались.

Если бы был обычное зеркалирование, ничего бы не случилось, данные можно было бы восстановить (без метаинформации), а в случае raid-z данные потеряны навсегда.

Оляля... и Вы туда же, ну прям страсти то какие, а внешнего стораджа у Вас нет конечно, Вы супер мега важную инфу храните на Blade серверах которые не прикручены, ужас, мои соболезнования, но у Вас было три диска, один удалили, на втором метадата посыпалась, а есть ещё третий диск, ведь RAID-Z создаёьться минимум из 3-х дисков, так вот, там останеться ещё один метадата блок, ибо их всего 3-и, для каждого метадаблока, кроме оригинального, а того получаеть 1+3, всего 4-е, на Ваши 3-и диска...;) А теперь попросите свою учительницу объяснить Вам, что Ваши теоретические синтенции не подкрепленны не одним фактом такого повреждения или падения, а вот, то что ряд больших контор использует именно raid-z/2 на Thumper-ахи не жужат, енто факт, по сему, вынужден Вам не поверить, ибо, что Вы там видели и как, мне не известно, ввиду, того, что интернет не как не гарантирует правдивости Ваших слов...;)

>Оляля...

Понятно, ни одного технического термина вы так и не привели. Как будете готовы, возвращайтесь :)

> Понятно, ни одного технического термина вы так и не привели. Как будете готовы, возвращайтесь :)

Бугага... сказать больше нечего??;) Хорошо, тогда засчитываю Вам слив и разрешаю удалиться...:-D:-D:-D

>Оляля... и Вы туда же, ну прям страсти то какие, а внешнего стораджа у Вас нет конечно, Вы супер мега важную инфу храните на Blade серверах которые не прикручены, ужас, мои соболезнования, но у Вас было три диска, один удалили, на втором метадата посыпалась, а есть ещё третий диск, ведь RAID-Z создаёьться минимум из 3-х дисков, так вот, там останеться ещё один метадата блок, ибо их всего 3-и, для каждого метадаблока, кроме оригинального, а того получаеть 1+3, всего 4-е, на Ваши 3-и диска...;) А теперь попросите свою учительницу объяснить Вам, что Ваши теоретические синтенции не подкрепленны не одним фактом такого повреждения или падения, а вот, то что ряд больших контор использует именно raid-z/2 на Thumper-ахи не жужат, енто факт, по сему, вынужден Вам не поверить, ибо, что Вы там видели и как, мне не известно, ввиду, того, что интернет не как не гарантирует правдивости Ваших слов...;)

Идиот в твоем raid-z может быть хоть 200 дисков, метаданные для восстановления ошибок живут только максимум на двух. Дошло?

>Идиот в твоем raid-z может быть хоть 200 дисков, метаданные для восстановления ошибок живут только максимум на двух. Дошло? да да и диски кажде 5 минут сяпятся только успевай менять, сразу как минимум половина ломается и тд и тп. мб вы просто зфс не осилили? =)

>>Идиот в твоем raid-z может быть хоть 200 дисков, метаданные для восстановления ошибок живут только максимум на двух. Дошло?

>да да и диски кажде 5 минут сяпятся только успевай менять, сразу как минимум половина ломается и тд и тп. мб вы просто зфс не осилили? =)

Сыпятся только два диска, на которых разбросаны метаданные. А 200 остальных в raid-z просто содержат данные, которые будут потеряны.

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

> Сыпятся только два диска, на которых разбросаны метаданные. А 200 остальных в raid-z просто содержат данные, которые будут потеряны.
> Не понимаете, что потерять 2 диска в большом хранилище очень просто, если при этом это два диска с метаданными, то теряется _весь_ массив данных.

А нафига оно такое нужно? Если это правда, конечно...

>А нафига оно такое нужно? Если это правда, конечно...

А вот так работает zfs - метаданные не попадают в raid-z, поэтому нужно делать дополнительный raid для всего, т.к. нет возможности положить метаданные на отдельный носитель. Если бы это было возможно, то проблема бы просто решалась raid'ом для метаданных (а так есть только миррор на один дополнительный носитель через ditto blocks), а так приходится делать raid для всего, при этом данные потом попадут еще и на raid-z.

В общем, сама технология raid-z очень неудачна.

> RAIDZ нельзя зделать из двух дисков, минимум из 3-х, как и любой RAID5

Утверждение не соответствует действительности. Сделать RAID-Z из _двух_ дисков вполне себе возможно, возьмите и попробуйте. Только это не имеет особенного смысла, поскольку обычное зеркало будет эффективнее.

> При выходе из строя диска в целом, например при его замене, могут пропасть все копии, поэтому солярис с zfs находится в серьезной зоне риска при выходе всего лишь одного диска из пула, т.к. не известно, куда дублируются блоки.

Такие утверждения нуждаются в обосновании. А с обоснованиями, видимо, будет туго. Читайте исходники, они рулез:

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/z...

> ZFS self-healing и этот пресловутый raid-z всего лишь маркетинговый ход (а вы повелись), т.к. работает все это заметно хуже обычного raid, т.к. легко позволяет терять данные.

Не буду утверждать, что RAID-Z состоит из одних сплошь достоинств, но вот то, что проблеме "write hole" он не подвержен - это точно. Утверждение о том, что RAID-Z позволяет легко терять данные, нуждается в обосновании

> Кстати, раз уж вы так любите это поделие, объясните, зачем дублировать данные, если они и так должны "восстанавливаться" из raid-z в случае ошибок (диска, контроллера, фс и т.п.)? А делается это для того, что raid-z - гавно, а mirror - нет, а т.к. уже все раструбили и отфанфарили, придется поддерживать кривую технологию, пусть хоть с костылями не рассыпается. Впрочем, как всегда в Sun.

Ditto-блоки позволяют поднять защиту данных на уровень выше зеркал и RAID-Z. Метаданные в ZFS хранятся в обычных логических блоках, которые реплицируюся на уровне зеркал или RAID-Z. Ditto-блоки позволяют сохранять несколько копий одного и того же логического блока с метаданными. Чтобы было понятнее, рассмотрим пример пула, состоящего из трех зеркал, каждое из двух дисков. В этом случае метаданные ZFS, для которых хранится 2 или 3 копии по умолчанию, на физических дисках будут представлены 4 или 6 копиями соответственно.

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

> Вы совсем не работали с железом? Обычные bad блоки появляются сначала по одному, потом пачками в районе первого, если он в области метаданных, они будут испорчены, если в области данных - будут повреждены только данные, Это самый распространенный случай поведения портящихся жестких дисков.

А что, если первый был в конце области метаданных, а следующие непосредственно за ним в области данных? Что будет повреждено - только данные или только метаданные? И самое главное, как вы об этом узнаете?

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

> Ваше незнание этого говорит о том, что вы понятия не имеете о том, о чем рассуждаете, и очень мало работали с настоящим оборудованием. Зато уже прочли рекламные статьи Sun.

Зато вы, видимо, работаете так много, что нет ни секунды времени прочесть хотя бы одну, даже рекламную ;-)

> А вот так работает zfs - метаданные не попадают в raid-z, поэтому нужно делать дополнительный raid для всего, т.к. нет возможности положить метаданные на отдельный носитель. Если бы это было возможно, то проблема бы просто решалась raid'ом для метаданных (а так есть только миррор на один дополнительный носитель через ditto blocks), а так приходится делать raid для всего, при этом данные потом попадут еще и на raid-z.

Бррр. Думаю, автору, прежде чем говорить такое, не мешало бы попытаться получше разобраться, как работает ZFS вообще и RAID-Z в частности. Для этого в сети есть уйма полезной информации, от статей до исходных текстов.

> В общем, сама технология raid-z очень неудачна.

Голословное утверждение. Любая технология может быть неудачной, если ее использовать не по назначению (забивать гвозди микроскопом гораздо неудобнее, чем молотком).

У любой технологии есть свои слабые и сильные места. Например, RAID-Z не лучший выбор для нагрузки, подразумевающей много мелких случайных операций чтения (нужно объяснять почему, или статьи почитаете?).

Но зато для корректной работы RAID-Z не требуется энергонезависимый кэш, что избавляет от необходимости использования специальных RAID-контроллеров и позволяет строить надежные системы на базе недорогих общедоступных компонентов. Впрочем, это может рассматриваться как крупный недостаток, если смотреть с точки зрения производителей этих самых RAID-контроллеров или массивов ;-)

Block devices within a vdev may be configured in different ways, depending on needs and space available: non-redundantly (similar to RAID 0), as a mirror (RAID 1) of two or more devices, as a RAID-Z group of three or more devices, or as a RAID-Z2 group of four or more devices.

Как метаданные положить на другой девайс в пуле, для которого может быть сделано зеркало? Если бы это было возможно, то зачем придумали ditto blocks? Что произойдет, когда на этом девайсе закончится место, а на остальных в пуле оно еще будет свободно?

Дело не в том, как работает raid-z, а как работает остальная часть, а конкретно как кладутся метаданные, которые нужны для работы raid-z. Я не говорю, что у raid-z нет плюсов, но недостатки полностью убивают все достоинства. собственно, поэтому mirror и используется чаще, т.к. в нем вообще нет проблем кроме рациональности использования дисков.

>А что, если первый был в конце области метаданных, а следующие непосредственно за ним в области данных? Что будет повреждено - только данные или только метаданные? И самое главное, как вы об этом узнаете?

И данные и метаданные будут повреждены, в зависимости от настроек избыточности что-то может быть восстановлено, что-то нет. Узнать тривиально - по несовпавшим контрольным суммам считанного блока и вычисленного значения. Вы придираетесь к отдельно взятым предложениям? Давайте сразу к сути.

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

И что с того? Я утверждаю, что при весьма легкодостежимом стечении обстоятельств raid-z не сможет спасти данные (хотя они могут быть вообще не повреждены), т.к. метаданные испорчены. Именно поэтому никто не использует переменный размер блока в raid, хотя и могли бы - суперблок для raid мог бы содержать эту информацию. Знаете, почему так не делают? Не потому, что так Джев Бонвик написал, а потому, что при потере метаданных пропадут и данные, а при фиксированном размере блока их можно восстановить.

>Ditto-блоки позволяют поднять защиту данных на уровень выше зеркал и RAID-Z. Метаданные в ZFS хранятся в обычных логических блоках, которые реплицируюся на уровне зеркал или RAID-Z.

О чем я и написал, что либо никакой защиты метаданных (ditto block есть костыль, т.к. всего одна (максимум две) копия). Если метаданные лежат на raid-z, то где лежат метаданные для этого raid-z? Снова на raid-z, тогда для него метаданные лежат на обычном vdev, а следовательно при его выходе из строя полетит весь массив. Хорошо, при выходе из строя его и его ditto-block копии.

>Ditto-блоки позволяют сохранять несколько копий одного и того же логического блока с метаданными. Чтобы было понятнее, рассмотрим пример пула, состоящего из трех зеркал, каждое из двух дисков. В этом случае метаданные ZFS, для которых хранится 2 или 3 копии по умолчанию, на физических дисках будут представлены 4 или 6 копиями соответственно.

mirror - идеальное решение всех проблем. Raid-z - нет.

>Как метаданные положить на другой девайс в пуле, для которого может быть сделано зеркало? Если бы это было возможно, то зачем придумали ditto blocks? Что произойдет, когда на этом девайсе закончится место, а на остальных в пуле оно еще будет свободно?

Это я к тому, что был сильно удивлен (не)возможностью положить метаданные отдельно от данных на другом носителе, для которого можно было бы настроить mirror или что-то еще. Можно только все для всех (данных и метаданных). Логи транзакций, насколько я помню, можно положить на отдельный девайс (но не на raidz).

Или вы наверное представляете себе случай, когда метаданные лежат на _том же_ самом raid-z, что и данные? Это самый печальный случай из всех - при повреждении блока с метаданными, raidz не сможет его восстановить, т.к. не знает размер, а размер лежит в испорченном блоке. Ditto block всего лишь уменьшает эту вероятность.

А вообще мне интересно, как система сможет восстановиться в этом случае, если есть только 3 носителя, объединенные в raidz, и идин из них не работает. Для чтения метаданных нужно их восстановить из оставшихся носителей, а для этого нужно считать метаданные... Замкнутый круг.

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

> Как метаданные положить на другой девайс в пуле, для которого может быть сделано зеркало?

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

>Если бы это было возможно, то зачем придумали ditto blocks?

Ditto-блоки придумали затем, чтобы для особенно важных данных, которыми, по умолчанию, считаются метаданные файловой системы, можно было хранить несколько физических копий на разных top-level vdev'ах (или на одном, но максимально далеко друг от друга, если других нет, или на них кончилось место)

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

Посмотрите, как реализовано выделение блоков в случае использования отдельных устройств для ZIL. Что-то похожее можно было бы использовать и для реализации отдельных метаданных.

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

> Дело не в том, как работает raid-z, а как работает остальная часть, а конкретно как кладутся метаданные, которые нужны для работы raid-z. Я не говорю, что у raid-z нет плюсов, но недостатки полностью убивают все достоинства. собственно, поэтому mirror и используется чаще, т.к. в нем вообще нет проблем кроме рациональности использования дисков.

Метаданные (указатели блоков и т.д.) храняться в логических блоках ФС, так что они реплицируются при записи на top-level vdev с избыточностью точно так же, как и любые другие логические блоки. При этом, при наличии трех или более top-level vdev'ов в пуле, дополнительные копии логических блоков, содержащих метаданные, будут помещены и на другие top-level vdev'ы, а если их нет или на них нет места - то на тот же vdev, но максимально далеко друг от друга.

Потерять что либо можно только в том случае, если все ditto-копии каких-то метаданных окажутся на одном top-level vdev и этот top-level vdev окажется неисправным целиком - то есть он исчезнет целиком (например, из-за неисправности контроллера) или в нем откажут одновременно два (в случае RAID-Z1) или три (в случае RAID-Z2 диска), да и в этом случае потеряется доступ не ко всем данным, а только к их части, причем идентифицируемой.

Впрочем, при одновременном выходе из строя двух(трех) дисков в обычно RAID-5(6) данные также будут потеряны, так что особой разницы между RAID-5(6) и RAID-Z(2) здесь не просматривается.

Сейчас, когда имеется свойство пула failmode, вполне уместно разместить RFE для улучшения механизма ditto-блоков таким образом, чтобы можно было гарантировать их расположение на разных top-level vdev'ах.

> О чем я и написал, что либо никакой защиты метаданных (ditto block есть костыль, т.к. всего одна (максимум две) копия). Если метаданные лежат на raid-z, то где лежат метаданные для этого raid-z? Снова на raid-z, тогда для него метаданные лежат на обычном vdev, а следовательно при его выходе из строя полетит весь массив. Хорошо, при выходе из строя его и его ditto-block копии.

Еще раз, поскольку метаданные храняться в таких же логических блоках, что и пользовательские данные, они, при записи этого логического блока на top-level vdev с ибыточностью, защищаются также, как и данные в любом другом логическом блоке. Копии uber-блоков хранятся на нескольких top-level vdev'ах в массиве uber-блоков, поэтому для них невозможна ситуация, чтобы все копии uber-блоков оказались на одном top-level vdev'е.

Ditto-блок - это не костыль, это еще один уровень защиты, аналога которому нет в обычных RAID'ах (да и не может быть, поскольку это происходит на другом уровне абстракции).

> mirror - идеальное решение всех проблем. Raid-z - нет.

Не идеальное, и вы сами об этом упоминаете. Цена может оказаться недопустимо высокой, например.

> И что с того? Я утверждаю, что при весьма легкодостежимом стечении обстоятельств raid-z не сможет спасти данные (хотя они могут быть вообще не повреждены), т.к. метаданные испорчены.

Может быть, вы опишете это легкодостижимое стечение обстоятельств?

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

Интересно, как вы себе это представляете?

> Знаете, почему так не делают? Не потому, что так Джев Бонвик написал, а потому, что при потере метаданных пропадут и данные, а при фиксированном размере блока их можно восстановить.

Это заблуждение. При повреждении метаданных любой файловой системы можно забыть про данные, которые они описывали. И это не зависит от того, фиксированный размер блока или нет, впрочем как и от того, фиксировано ли положение этих метаданных на диске или нет. При фиксированном размере полоски RAID можно будет прочитать лишь все неповрежденные полоски, но это не означает возможности восстановить данные. Можно лишь восстановить их отдельные куски, а потом пытаться собрать из них нечно, напоминавшее данные, но без каких бы то ни было гарантий

> Или вы наверное представляете себе случай, когда метаданные лежат на _том же_ самом raid-z, что и данные? Это самый печальный случай из всех - при повреждении блока с метаданными, raidz не сможет его восстановить, т.к. не знает размер, а размер лежит в испорченном блоке. Ditto block всего лишь уменьшает эту вероятность.

Ясно. Размер логического блока хранится не в нем самом, а в указателе на этот блок. Смотрите

http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/fs/z...

Cамый верхний блок (uber-блок) всегда хранится на нескольких top-level vdev'ах (если из больше одного, конечно), это во-первых, а во-вторых, на каждом vdev'е, из которых состоит top-level vdev. (смотрите vdev_uberblock_sync()).

> А вообще мне интересно, как система сможет восстановиться в этом случае, если есть только 3 носителя, объединенные в raidz, и идин из них не работает. Для чтения метаданных нужно их восстановить из оставшихся носителей, а для этого нужно считать метаданные... Замкнутый круг.

Никакого замкнутого круга. Было бы странно, если бы ZFS не могла работать в таком простом случае. Начинаем плясать от корневого указателя (который хранится в uber-блоке на двух выживших дисках), и идем вниз по дереву, восстанавливая логические блоки, в которых храняться метаданные с помощью четности RAID-Z, а если не получится (например, контрольная сумма восстановленного блока окажется неправильной) - то с помощью ditto-блоков. Поскольку ditto-блоки при этом будут пространственно разнесены, то есть очень большой шанс все-же отыскать все данные, даже если начал сыпаться какой-то из выживших дисков. Что происходит с аппаратными RAID'ами, когда отказывает один диск и при этом начинает сыпаться еще один, думаю, рассказывать не надо.

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

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

> Утверждение не соответствует действительности. Сделать RAID-Z из _двух_ дисков вполне себе возможно, возьмите и попробуйте. Только это не имеет особенного смысла, поскольку обычное зеркало будет эффективнее.

Зделать его конечно можно и из _двух_ дисков, можно и из _одного_, только вот зачем, когда речь шла про нормальный raid-z, который, даст какую-то степень избыточности, а не приз за глупости...:)

> Зделать его конечно можно и из _двух_ дисков, можно и из _одного_, только вот зачем, когда речь шла про нормальный raid-z, который, даст какую-то степень избыточности, а не приз за глупости...:)

Ошибочка - из одного диска сделать RAID-Z нельзя (хотя в зеркало один диск превратить можно). Степень избыточности двухдисковый RAID-Z даст такую же, как и двухдисковое зеркало, но эффективность будет ниже, поскольку содержимое второго диска придется вычислять.

> Ошибочка - из одного диска сделать RAID-Z нельзя (хотя в зеркало один диск превратить можно). Степень избыточности двухдисковый RAID-Z даст такую же, как и двухдисковое зеркало, но эффективность будет ниже, поскольку содержимое второго диска придется вычислять.

Ох... началось, берём слайс, в нём 7-м партиций, я создаю из этих партиций raid-z, в чём проблема???:)

Raid-z можно создать, как в прочем и пул из файлов, партиций в слайсе и жёстких дисков целиком, так что не вижу проблемы, создать из одного диска raid-z массив, вижу только одно, зачем так извращаться??:)

> Ох... началось, берём слайс, в нём 7-м партиций, я создаю из этих партиций raid-z, в чём проблема???:)

Проблема в производительности того, что получится в результате :-) С другой стороны проблема в нежелании признать неточность исходного утверждения.

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

Согласен, было бы правильнее в данном контексте говорить о количестве vdev'ов, из которых можно или нельзя создать RAID-Z. Впредь буду стараться выражаться яснее.

Заговорился :-) Конечно же, в исходном сообщении утверждалось, что RAID-Z нельзя создать из двух дисков. Исправляюсь и прошу прощения.

Проблема в производительности того, что получится в результате :-) С другой стороны проблема в нежелании признать неточность исходного утверждения.

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

Согласен, было бы правильнее в данном контексте говорить о количестве vdev'ов, из которых можно или нельзя создать RAID-Z. Впредь буду стараться выражаться яснее.

Согласен, что тоже был не совсем коректен, когда сказал про 2-а диска, посколько имел ввиду, что данная ситуация приведёт к сомнительной производительности и не явным последствиям...:)