>Ну так в ZFS зеркало тоже есть. И потом, обычный пул при
>необходимости можно легко превратить в гибридный. Только зачем в этом случае ZFS? Что бы все тормозило из-за COW(напомню, у нас задача database сервер), и нельзя было занять больше половины совсем недешевого объема SSD-дисков? Вспомним так же о нецелевом расходовании ОЗУ... А если у этой машины меньше 8 Гигов ОЗУ? на Xeon54[0-9]\{2\} таких машин(которые не могли съесть больше 8 гигов, и были достаточно бюджетные) было достаточно много.
Имхо, mdraid/gmirror как raw device (точнее, в Linux LVM-том сверху mdraid) будет гораздо более адекватным выбором!
>>raid это девятки после запятой в надежности работы сервиса. Контроль целостности нужен
>>для добавления девяток, что бы _уменьшить_(но не исключить) необходимость восстановления из
>>бэкапов
>
>Еще раз - RAID и контроль целостности не связаны друг с другом.
>Контроль целостности может быть без RAID, и RAID без контроля целостности
>тоже. И оба вместе могут быть
Контроль целостности это не более чем одна-две девятки после запятой к надежности, аптайму, но не гаратии сохранения данных, которую может дать только off-site бэкап! Еще одна фича рейд-массивов (в аппаратных, например, такой фичей является батарейка, защищающая кэш, или флэш-память, а так же контроль четности блоков данных, гарантирующих в 5-6-м рейдах восстановление битых блоков данных)
>>в случае железных проблем, или совсем бюджетного железа (без ECC памяти), или
>>некоторых софтовых глюков (наверное, самый частый случай) ZFS будет закономерно писать
>>на диск уже испорченные данные, испорченные до попадания их к ZFS.
>
>Блин, да этому подвержена любая файловая система, причем тут ZFS?
При том, что в ряде случаев проверка целостности данных ZFS, с которой тут так носятся, это ненужная фича, лишь еще одна девятка после запятой, которая нужна не всем, и которая имеет свою, совсем не дешевую цену.
>>>А я бы предпочел, чтобы за меня это делал компутер, он ведь
>>>для этого создан. Зачем мне лишняя забота - поддерживать в актуальном
>>>состоянии контрольные суммы бэкапов?
>>
>>ZFS Вам _не_ может дать такой гарантии.
>
>Сумбур у вас в мыслях какой-то. Вы предлагаете класть рядом с каждым
>файлом еще один небольшой файлик хэшем. Я говорю, что мне такой
>геморрой ни к чему, файловая система с этим справится гораздо лучше.
Это у Вас сумбур. Та же Bacula прекрасно умеет работать с хэшами, для бэкапа GNU tar/ssh разумнее считать хэш до передачи серверу бэкапов, на стороне клиента, так как при передаче по сети бэкап уже может испортиться
>Вы начинаете про какие-то гарантии.
Именно! Контроль целостности данных, это лишь еще одна девятка после запятой в степени гарантии стабильности сервиса, и _не_более_!
>Так можно договориться до того, что компьютеру вообще никаких задач доверять нельзя,
>ибо гарантировать целостность всего и вся невозможно. Но однако же люди
>этим пользуются. А все потому, что допускают какой-то уровень ошибок.
Ну вот Вы и поняли мою мысль: контроль целостности данных нужен _не_всегда_, так как он имеет свою, весьма недешевую цену
>>>А под ручку со сквозным контролем целостности ходит обнаружение и исправление ошибок
>>>при наличии избыточности.
>>
>>Оно не дает никаких гарантий того, что Ваши данные будут целостны. Их
>>могут дать _только_ бэкапы, и процедура переодического восстановления из бэкапов (и
>>тестов того, что восстановлено), и то, с оговорками
>
>Я не говорю об абстрактных гарантиях целостности данных в вакууме. Я говорю
>о сквозном контроле целостности данных при их хранении долговременном хранении на
>дисках и передаче из памяти на диск и обратно.
А зачем это, если память, например, не ECC, и приложение работает не очень стабильно?
Нет смысла обеспечивать "сквозной контроль целостности" ненужная фича, да еще и достаточно дорогая (куча оперативки, общая тяжеловесность ZFS, фрагментация, и т д)
Или, например, это видео-хостинг, где один битый пиксель видео-файла за год ни на что не повлияет?
>Так вот, если данные хранятся с избыточностью, контроль целостности позволяет, во-первых, существенно
>расширить класс обнаруживаемых ошибок - от явных типа полного отказа и/или
>ошибок чтения/записи, с обнаружением и обработкой которых неплохо справляется RAID, до
>явных + неявных, вроде фантомных записей и прочих веселостей, которые RAID
>не обнаруживает, а во-вторых, попытаться исправить ошибку, используя имеющуюся избыточность.
Это лишь один из методов. Вместо этого, специализированная система мониторинга вроде Zabbix/Nagios позволит выявить ошибку в работе приложения, а не фантомные изменения в одном пикселе.
Кучу раз видела сервера под той же FreeBSD с UFS с сотнями файлов в lost+found после жестких ребутов, и... они работали, представляете? Даже без журнала!
>[оверквотинг удален]
>>raid6 для хранения данных без требования высокой производительности), хотя еще играет
>>роль то, что raid6 вообще надежнее на современных больших дисках, с
>>которыми вероятность вылета второго HDD во время ребилда не так уж
>>и мала.
>
>Вы смешиваете в одну кучу RAID и контроль целостности.
>Есть
>RAID-5 из 4 дисков плюс диск для четности. Есть полоска RAID,
>в которой содержимое дисков с данными не совпадает с вычисленным содержимым
>диска с четностью. Ваши действия? Как RAID-5 поможет вам гарантировать целостность?
Я Вам уже в прошлый раз сказала, что Вам не хватает знаний. Читайте доки не только про ZFS, расширьте кругозор, почитайте те же IBM-овские редбуки, узнаете много нового.
>[оверквотинг удален]
>основании этой информации вы можете сделать вывод о том, где эта
>ошибка - на каком диске. Если диск установить не удается, это
>может означать что ошибка была внесена в данные, пока они еще
>были в памяти, но уже после того, как была вычислена их
>контрольная сумма.
>
>Если контроль целостности ошибок не показывает, но ошибка тем не менее есть
>(с точки зрения приложения), то может сфокусироваться на поиске ошибок в
>памяти, приложениях, ядре и т.п., исключив все компоненты связанные с передачей
>и долговременным хранением данных на внещних носителях.
Вместо этого проще мониторить работу приложения :) Чем вводить дополнительные абстракции в виде ZFS, которая все равно не может гарантировать нахождения на диске целостных данных.
На файлопомойке с какими-то отвественными данными, ECC registred памятью, двумя блоками питания (с отключением работающего нестабильно, что бы память/cpu/мосты всегда работали стабильно), несомненно, сквозной контроль целостности данных ZFS более чем пригодится, и он тут будет лучшим в мире :)
>>с ZFS все точно так же: сквозной контроль целостности часто слишком избыточен,
>>и совсем не нужен для проекта, если остальные компоненты системы совсем
>>не такого уровня защиты.
>
>Если вы считаете, что в контроле целостности нет никакой пользы, то я
>уже и не знаю, как вам объяснять. Думаю, подрастете - поймете.
>Или когда на собственной шкуре испытаете, что такое искать неявную ошибку
>в сложной системе, особенно состоящей и продуктов разных производителей.
Предлагаю Вам самому подрасти, и почитать, хотя бы, как работает raid5/6, а то, похоже, что Вы сознательно ограничили свой кругозор ZFS, FreeBSD, Solaris(?), даже про device-mapper пытаетесь рассуждать, не зная, что это, но самое главное, повторюсь, пытаетесь сравнивать ZFS с raid5/6, при этом не подозревая о том, как он работает!
>>Больше вопрос в iops'ах, с которыми у ZFS не всегда все хорошо
>
>Эээ. Сквозной контроль целостности - это контрольные суммы. Причем тут IOPs'ы?
COW есть причина тормозов во многих случаях, которая лечится только дополнительными шпинделями и другими _дорогими_ и излишними ухищрениями.
Так как контроль целостности лишь одна из фич рейда, повышающая его надежность, зачем она в половине задач? Если не поняли, прочитайте еще раз, если опять не поняли, вернитесь к моему прошлому примеру из raid5, почему его выбрали вместо шестого на виртуальной задаче, тогда как он менее надежен
>>>А как насчет раннего обнаружения этих самых ошибок, чтобы они не попали
>>>в самые глубокие офф-сайт бэкапы?
>>
>>Для этого есть мониторинг. ZFS не может гарантировать того, что на ZFS
>>у Вас верные данные!
>
>Мониторинг без контроля целостности может быть позволит вовремя заметить некоторые явные ошибки.
>Неявные ошибки мониторинг не найдет.
А их нужно находить, если все и так работает?
>ZFS не претендует на гарантирование того,
>что данные, поступившие ей от пользователя, верны.
Именно!
>Но по крайней мере
>она гарантирует, что ошибки при передаче и хранении будут обнаружены.
А зачем это, если гораздо больше вероятность того, что данные будут испорчены из-за ошибки приложения/памяти/cpu? по крайней мере на SOHO/SMB железе/серверах?
Только лишние сложности и сущности, которые противоречат приципу KISS.
