>> Если диски не битые, то без разницы
>
>Ну почему же: на одном могут быть правильные данные, на другом -
>нет, так что разница есть - в одном случае вы исправите
>плохую копию и восстановите избыточность, в другом - уничтожите последнюю хорошую.
>
>
>> если ФС сверху журналируемая, ничего плохого не произойдет
>
>см. пример выше; вдруг это произойдет для блока журнала?

Не бывает плохих или хороших данных для зеркала. Зеркало вообще не проверяет консистентность блоков данных и метаданных! Если метаданные различаются, рейд ресинкается, и все (других вариантов нет)

Вы в любой момент можете изъять из зеркала любую из его половин, и ничего не потеряете, так как на обе половины консистентны.

Более того, на другая половина так же консистентна :) "Правильные данные" и зеркало это совершенно перепендикулярные понятия, оно вообще не проверяет блоки между дисками на консистентность.

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

Именно по этой причине нет никаких веских причин не использовать софт-зеркала в отственных проектах (в отличае от 5/10/6 и т д)

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

При исправности же носителей, нет никакой разницы с какого из дисков синкать данные, и понятие "правильности" диска просто не применимо и оторвано от реальной практики, и является демагогией.

>> Извините, я уже и так достаточно много рассказала, чего Вы, по всей видимости, не знали(должно быть стыдно, так как азы :)) ).
>
>А вы забавная. Я ведь даже не просил все это рассказывать -
>все это расписано в документации, книжках и так далее. Я всего
>лишь задавал вопросы, рассчитывая, что они заставят вас задуматься. Видимо, пока
>не заставили.

Вас тоже :) Вы не понимаете, как работает софт-зеркала(и hardware), и не понимаете, что чексуммы данных, имеющиеся в zfs, это не панацея на любой случай в жизни (а в ряде случаев, особенно на плохом оборудовании вроде "серверов" без ECC памяти(на которые так часто в бюджетных ДЦ ставят фрю) откровенно бесполезная фича, так как из ОЗУ могут попасть уже битые, но с точки зрения ФС консистентные данные - но не приложения!)

Стоит так же вспомнить про многочисленные баги, которые есть в любых приложениях, сбоях даже при ECC памяти при перегреве, например, сервера, и т д. То есть, нет технической возможности в 100% случаев обеспечить на дисках именно то, что мы рассчитываем там увидеть.

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

>[оверквотинг удален]
>того же количества дисков). Знаете какими?
>
>> а по производительности, raid10 в ряде случаев просто безальтернативен(особенно при интенсивном i/o на запись в четырехшпиндельных серверах), а его zfs предложить не может (в отличае от md или geom)
>
>Строго говоря, вы правы - ZFS не предоставляет прямого аналога RAID-0, то
>есть механизма строго детерминированного распределения блоков данных по блокам дисков, входящих
>в RAID-0. Однако на уровне пула ZFS осуществляет динамическое чередование своих
>логических блоков по устройствам верхнего уровня в пуле. То есть пул,
>состоящих из двух зеркал можно с некоторой натяжкой называть аналогом RAID
>1+0.

Попробуйте рассказать, но не думаю, что человек, не понимающий как работает зеркало, может рассказать что-то новое.
Уверяю Вас, про zfs я читала, ставила Solaris что бы посмотреть, и обдумываю о вариантах использования в том числе с фрей под узкую задачу - файлопомойки (так как в остальных случаях lvm и clvm мне кажутся гораздо мощнее и приспособленнее к реальным условиям и требованиям)

>> но 10-ку использовать без bbu можно только на некритичных задачах (думаю, очевидно почему), поэтому raid10 через geom/md это совсем low end, когда _нужно_ быстро, а денег нет совсем.
>> Но по-нормальному, на этой задаче нужен аппаратный контроллер с bbu
>
>BBU - это тоже не панацея. BBU имеют свойство выходить из строя
>в самый неподходящий момент, требуют периодического обслуживания и замены, позволяют сохранять
>содержимое кэша в течение ограниченного времени, привязывают к определенной модели или
>определенному производителю контроллера. Некоторых это заставляет покупать по два контроллера и
>один класть в стол (что не помогает сохранению собственно BBU). И
>эти минусы могут перевесить плюсы даже не в low-end решениях. Хотя
>надо признать, что это достаточно распространенные и во многом понятные решения.

bbu без проблем мониторится(тот, кто не использует что-то вроде Nagios или Zabbix, и т д, имхо, сам себе клинический идиот) :) Кстати, уже есть контроллеры без BBU, но с флэш-памятью.
Я думала, тут вы запоете в очередной раз песню про чексуммы данных в zfs, и то, то hw-контроллеры не проверяют непосредственно данные, а только блоки данных в raid5/6, но, похоже, Вы про это не знали :)