>>Я рад, что здравый смысл все-таки возобладал.
>
>Если я перед Вами извинилась, и признала то, что вела с Вами
>себя просто по-свински, это не означает, что согласилась с предметом спора. Я вижу. Я только одного не понимаю - в моем предыдущем ответе ZFS нигде не упомянута (разве что в заголовке), речь идет про RAID и отсутствие в нем контроля целостности, вопреки вашим утверждениям. Вы же упорно возвращаетесь к ZFS, выгодам, нужности/ненужности. Зачем? Контроль целостности есть не только в ZFS, поэтому вполне может рассматриваться самостоятельно. Выгода и нужность/ненужность - вещи субъективные, поэтому чего о них спорить? Вы скажете выгодно, я скажу нет, и каждый будет прав по-своему.
Но это никак не отменит того факта, что RAID1/5/6 гарантирует защиту только от явных ошибок дисков.
Впрочем, в ZFS контроль целостности весьма неплохо реализован, так что можно ее можно использовать, чтобы говорить о контроле целостности не как о некоторой абстрактной "фиче", а как о конкретной реализованной возможности :-)
>А ее и с ZFS тоже нет, почему см. выше.
В том смысле, который в это вкладываете вы - действительно нет. Вот только беда в том, что если доводить все до абсурда, то придется признать, что вычислительной техникой лучше не пользоваться вообще, так как вероятность ошибки всегда существует.
>В 6-м рейде это есть, есть в ряде случаев и в пятом.
Вобщем, я не знаю как еще объяснять, что RAID1/5/6 гарантированно защищают только от явных ошибок дисков. Кое-какие дополнительные проверки там возможны (и соответствующие примеры рассматривались), только вот на практике их не используют, потому что гарантий они не добавляют, а негативное влияние на производительность оказывают.
В случае RAID6 при полной избыточности еще можно пытаться делать перебором поиск диска, содержащего неправильные данные, в случае обнаружения рассогласования содержимого дисков с данными с содержимым дисков с четностью, при условии, что только содержимое только одного диска неправильно, а содержимое всех остальных правильно. Но опять же на практике так никто не делает, насколько мне известно. Во всех остальных случаях - гарантий нет.
>Не нужно это в больше чем половине задач, особенно если железо не
>очень хорошее.
Даже если железо не очень хорошее, в результате можно ограничить область распространения ошибки, ограничить область поиска ошибки, что для не очень хорошего железа лишним не будет, в силу того, что в не очень хорошем железе возможности диагностики зачастую тоже далеки от очень хороших.
>Это фича, как и в ZFS фича сквозной контроль целостности, так как
>позволяет бороться с "родовой травмой" жестких дисков :)
Ладно, уговорили, только вот почему только "родовой травмой" жестких дисков? Ошибками во всем стеке ввода вывода уж тогда. Ну и в ZFS вы можете этот контроль целостности для своих данных и отключить (и сэкономить какие-то крохи процессорного времени), но для метаданных его отключить нельзя, поэтому гарантиями, предоставляемыми контролем целостности, ZFS для своих метаданных будет продолжать пользоваться. В случае RAID5/6 без батарейки получаются не только тормоза, но и "Write Hole".
>Еще раз, куда вероятнее, что ошибка произойдет в памяти, или в приложении, или даже в CPU (отказал куллер, отказал мониторинг, пошли ошибки, это гораздо вероятнее, кроме того данные в памяти, и тут может даже и ОС упасть
пусть падает - это не страшно, это как раз таки способ ограничения дальнейшего распространения ошибки - аварийно завершить работу, чтобы дать возможность средствам диагностики и/или кластеризации сделать свое дело.
>Кто-то для критичных сервисов отменил репликацию БД, и контроль данных средствами приложений?
Никто, конечно, не отменял. А что если приложение контроль не делает? Ну вот досталось оно вам такое и никуда не денешься? Или реплицировать некуда, бюджет не позволяет? Как то бы уже определиться - все таки он есть или его нет.
Кстати, о бюджете. Аппаратный RAID-контроллер тоже отдельного бюджета требует :-) Ведь нужно купить контроллер, купить поддержку (ну или еще один на всякий случай. А ZFS - доступна и за так.
> Еще раз: тут бинарная логика,
Эх, если бы все было так просто.
> но с некоторыми задачами она справляется не очень хорошо (поиск ошибок в работе сервиса лучше получается у специализированного мониторинга, зачем плодить сущности?)
А кто вам сказал, что ZFS занимается поиском ошибок в работе сервиса? Она занимается своим делом - хранением данных, и либо делает это хорошо, возвращая именно те данные как были сохранены, либо честно признается, что не смогла, сигнализируя об этом приложению, и сообщая об обнаруженной ошибке тому, кто действительно занимается сбором рапортов об ошибках от всех подсистем, а не только от файловой системы, поиском корреляций, постановкой диагноза и принятием необходимых мер. В OpenSolaris'е этим занимается демон fmd, являющейся одним из составных элементов Fault Management Architecture - системы (архитектуры) управления сбоями. Вот только не думаю, что вместе с ZFS Брайан портировал в Линукс и FMA. Да и зачем - если все из OpenSolaris в Линукс портировать, то OpenSolaris ведь получится :-)
Вобщем, мне все ясно. Вам это не нужно, ваши задачи и задачи ваших клиентов этого не требуют, либо вы не видите, где это можно применить, либо сознательно отказываетесь видеть. Вот и славно. Мне - нужно, плюсы я продемонстрировал, минусы тоже. Надеюсь, тот, кому нужно и интересно - тот увидел и сделал выводы.
