mdadm raid1 на чтение ведет себя как raid0?

как сказать...
на hardware-raid'ах может быть алгоритм проверяющий идентичность данных на обоих дисках и в случае отличия выдавать ошибку чтения. К тому же текущий режим чтения (поочередно запрашивающий данные с разных дисков) чреват опастностью потери данных, сейчас поясню почему. Сегодняшние hdd могут быть выведены из строя по нескольким причинам, но по факту может умереть электроника (тогда диск либо не определяется, либо определяется неверно), может умереть механика (в принципе симптомы те же), но может быть проблема с чтением/записью информации из/в определенных кластеров - некоторые насколько износились (слово неверное, но наиболее лучше характиризует симптомы) что операции с ними производятся непомерно долго, и hdd может посчитать что это сбойный кластер и вернуть ошибку чтения (или записи). Теперь вернемся к mdadm raid: я не знаю деталей как он раскидывает запросы (случаным образом, по нагрузке на диск, может быть вычисляет остаток от деления адреса блока на кол-во дисков в зеркале и направляет запрос на диск с этим номером), но даже в самом худшем случае может быть что обпределенный блок раз за разом читается из одного диска (т.к. mdadm уверен что второй хранит точно те же данные - sync был выполнен корректно и проблем с диском не было), однако на втором диске обращение к кластеру, который содержит те же данные уже может не завершаться успешно - кластер уже не читается из-за превышения timeout, и тогда в случае выхода первого диска из строя mdadm будет продолжать работать, однако sync на новый диск (замену вышедшему из строя первому) не сможет завершиться из-за ошибки чтения. В идеале (наиболее рациональный сценарий) mdadm должен раскидывать запросы так, чтобы очереди запросов на дисках были одинаковой глубины - это даст наибольшую производительность - если один из диском будет начинать умирать и медленнее работать, на него будtт приходить меньше запросов. Но это в идеале (другие сценарии - случайно или по очереди), и даже в этом случае из-за меньшего кол-ва запросов на диску будет труднее обнаружить уже не работоспособный кластер. В общем фича полезная - увеличивает производительность массива, но при этом теряется надежность зеркала.
К слову - ведет ли себя так raid5 - читает данные из N-1 дисков всегда (т.е. при, допустим, четырех, чтение каждого блока выполняется из трех, и если на него припал parity - идет восстановление исходных данный программно, вместо того чтобы прочитать данные из всех четырех, высчитать значение parity на основании текущих данных и сравнить её с записанной? Да, последнее звучит избыточно, однако поможет сразу же находить проблемы с диском, не дожидась пока данные умрут окончательно. Я помню что у mdadm был timeout на операции с дисками (если они отвечают дольше положенного диск помечается как сбойный), но я на hdd такой ситуации не видел, например у меня есть диск, у которого в некоторых участках чтение/запись проседяет до единиц Мб или даже до сотен Кб, диск не используется, но он был в raid5 и массив тормозил при работе с этими участками, из-за диска, но сам диск mdadm не выбрасывал как проблемный, хотя по правильному надо было бы, и единственное что сигнализировало что диск умирает - smart. В этом случае выход любого другого диска в этом же массиве мог мне причинить очень много головной боли. Во-первых, resync, который может занять непомерно долго времени, во-вторых, этот самый resync может и не завершиться успешно из-за ошибок чтения.
Ответ получился длинный и содержит довольно много повторений. Прошу за это прощение, я ставил цель как можно детальнее описать то, чего опасаюсь при работе mdadm.