>> Так и не поняла, ждете Вы от меня ответа, или ответили кому-то еще (так как вела себя в отношении Вас действительно отвратительно, не знаю, что на меня нашло),
>
>Я рад, что здравый смысл все-таки возобладал. Если я перед Вами извинилась, и признала то, что вела с Вами себя просто по-свински, это не означает, что согласилась с предметом спора.
>> Любой контроллер, если диски не десктопные, и не пытаются сами обрабатывать ремапы, _знает_ о ремапе, поэтому ситуация i/o ошибки, при чтении данных, должна обрабатываться верно (или вообще выкидыванием диска, или ремапом с помощью контроллера)
>
>Вы тут про явные ошибки говорите. А еще бывают неявные, и чем
>дальше пухнут диски, уплотняется запись, увеличиваются размеры и усложняется микрокод этих
>дисков, сокращаются сроки выхода их на рынок, тем неявных ошибок становится
>больше. И это не только к дискам относится, это относится и
>к аппаратным RAID-контроллерам тоже. И это не мои измышления, это подтверждается
>исследованиями. Например, CERN еще в 2007 году исследование специально на эту
>тему проводил: http://indico.cern.ch/getFile.py/access?contribId=3&sessionI...
Ну да, еще у NetApp было исследование (о том, что raid5 Must Die, в связи с размером дисков)
>>Что касается случаев "просто отличаются данные", ну что ж, не повезло.
>
>Вот так просто - "ну что ж, не повезло"? А как же
>надежность и все такое прочее?
А ее и с ZFS тоже нет, почему см. выше.
>>Если Вы еще раз внимательно перечитаете нашу дисскуссию, мой основной тезис был о том, что сквозной контроль четности всего навсего еще одна (или две) девятки к _надежности_ сервиса и его аптайму, не всегда нужные.
>
>А как же расширение класса обнаруживаемых ошибок, возможность исправление ошибок при наличии
>избыточности, возможность предотвращения дальнейшего распространения ошибки? Возможность изоляции источника ошибки, наконец?
В 6-м рейде это есть, есть в ряде случаев и в пятом. Завтра появится что-то кроме ZFS, которое добавит какой-то новый элемент к _стабильности_ сервиса (какую-нибудь гарантию переноса данных от приложения на диск, даже через сеть в точном виде), но все равно полной надежности сервиса достичь не получится.
Не нужно это в больше чем половине задач, особенно если железо не очень хорошее.
>[оверквотинг удален]
>неуместно.
>
>Вот еще:
>
>>Еще одна фича рейд-массивов (в аппаратных, например, такой фичей является батарейка, защищающая кэш, или флэш-память, а так же контроль четности блоков данных, гарантирующих в 5-6-м рейдах восстановление битых блоков данных)
>
>Энергонезависимая память (ака "батарейка") - это не просто "фича", это в RAID5/6
>средство борьбы с родовой травмой, известной как Write Hole. Без нее
>RAID5/6 не может _гарантировать_ корректность своего функционирования в случае внезапного пропадания
>питания.
Это фича, как и в ZFS фича сквозной контроль целостности, так как позволяет бороться с "родовой травмой" жестких дисков :)
>Потом, что вы понимаете под надежностью сервиса? Сервис, который оперирует ошибочными данными,
>выдавая непонятно какие результаты - это надежный сервис или нет? А
>что, доступ к дискам есть, какие-то данные читаются, записываются, машина работает,
>процессы выполняются, аптайм не пострадал. Выходит надежный сервис? Или нет?
Естественно, это менее нестабильный сервис. Но в ряде случаев даже raid5 выгоднее, чем raid6, см. выше мой пример.
Более того, для ряда задач, особенно SOHO/SMB, это будет _избыточно_ стабильно.
>[оверквотинг удален]
>надежности и доступности сервиса это имеет опосредованное отношение, так как если
>блочное устройство будет доступно, но база данных, на нем хранящаяся, будет
>падать, из-за того, что получает назад совсем не то, что записывала,
>то что будет с надежностью и аптаймом сервиса, построенного сверху этой
>базы данных?
>
>Конечно, если рассматривать как сервис предоставление блочных устройств для их использования кем-то,
>то да, улучшенная по сравнению с отдельным диском доступность RAID1/5/6 будет
>означать улучшенную доступность сервиса, но надежность этого сервиса все равно будет
>не очень.
"Не очень" для кого? Кроме того, в ряде случаев, raid5/6 (особенно 6) может гарантировать восстановление данных в лабораторных условиях(далеких от реальных), в которых Вы показываете преимущества ZFS, которые и так очевидны, но не так очевидна их полезность кроме некоторых _специальных_ применений.
Еще раз, куда вероятнее, что ошибка произойдет в памяти, или в приложении, или даже в CPU (отказал куллер, отказал мониторинг, пошли ошибки, это гораздо вероятнее, кроме того данные в памяти, и тут может даже и ОС упасть, не говоря о том, что какие-то данные испортятся на диске)
>Конечно, есть сервисы типа гугла, где нет особой разницы, сколько ошибок в
>результатах поиска, если этих результатов много. Но это скорее исключение, чем
>правило, это во-первых, а во-вторых, связанным с этим сервисом задачам типа
>учета количества показов рекламы надежность уже не по барабану.
Кто-то для критичных сервисов отменил репликацию БД, и контроль данных средствами приложений?
>> Почему это выродилось в поливание друг друга грязью, сперва осторожное, а потом острое, я не понимаю :(
>
>Вобщем, не обижайтесь, тезисов у вас было много разных, а вот с
>обоснованием их было не очень. Поэтому все и скатилось туда, куда
>скатилось. Но, как говорится, кто старое помянет... :-)
--------------------
Еще раз: тут бинарная логика,
- Либо ZFS это _исключительно_ средство хранения данных (для домашней фотоколлекции под эту роль, наверное, подойдет), в которой оно никак не смотрится, если только не используется под backup-сервер, на котором она будет более чем к месту (хотя ленты, особенно под zero-копии, имхо, интереснее) для, например, инкрементов и одной-двух последних zero. Хотя VTL с ZFS на рынке пока особенно не видно, (поправьте, если не права)
- Либо это средство повышения стабильности работы самого сервиса, и тогда улучшенный поиск ошибок, сквозной контроль целостности, и т д, это лишь фичи высокой доступности (чем быстрее мы найдем ошибку, тем быстрее поднимем сервис, тем больше по итогам года у нас будет девяток), но с некоторыми задачами она справляется не очень хорошо (поиск ошибок в работе сервиса лучше получается у специализированного мониторинга, зачем плодить сущности?), а ценность некоторых в большинстве применений сомнительна.
Так же она не очень хорошо смотрится для сервисов с высокими пиковыми нагрузками (по i/o, и, например, временному занятию большей части доступного места)
Если бы все вертелось вокруг необходимости восстановления блоков данных, никто бы на критичных к производительности и доступности сервисах не использовал raid10
--------------------
Вы опять начинаете переход на личности, давайте тут и сейчас прекратите, или извинятся, в следующий раз, придется уже Вам :)
