= Сообщение: 5797 из 8277 ========================================= RU.LINUX = От : Viktor V. Kudlak 2:5030/1374 14 Aug 19 13:41:30 Кому : Eugene Grosbein 14 Aug 19 13:41:30 Тема : Adaptec 2405 FGHI : area://RU.LINUX?msgid=2:5030/1374+5d53e82c На : area://RU.LINUX?msgid=grosbein.net+17efd136 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.LINUX?msgid=grosbein.net+106f6025 ============================================================================== Hello Eugene.
14 Aug 19 15:17, you wrote to me:
EG> 13 авг. 2019, вторник, в 23:13 NOVT, Viktor V. Kudlak написал(а):
VVKV>> Всё оно так, всё оно верно. но ни один программный код не VVKV>> идеален и для компенсации производительности часто используются VVKV>> хаки. на таких скоростях, как работают рейды современные, если VVKV>> система будет дожидаться окончания действия, то деградация VVKV>> производительности будет колоссальной.
EG> Чушь это всё, для по-блочного зеркала нет никаких проблем EG> алгоритмизировать производительное и корректное решение.
Спустимся на протокол скази и вероятность ошибки?.. окей. где хранится информация о том, какая копия самая актуальная (каунтер операций) (логический уровень томов) по средствам чего он там фиксируется? как часто обновляется? сколько операций требуется для его обновления и есть ли транзакционность в операциях? как в СУБД например. ACID, всё, либо ничего... на сколько мне память не изменяет -- нет там транзакционности... и как следствие - есть вероятность отказа. да, ничтожна, т.к. операции достаточно надёжны.. но на моей практике тоже бывали случаи... долго разбирались почему... один диск ушел в юстировку температурную, другой отказал, рейд в растерянности ушел в ожидание, прилетел скачок питания, диск из кешей в этот момент записал часть информации и вот тебе подобная ошибка...
еще скажи, что бред ошибок процессора. он же только два+два складывает и пять никогда не выдаст. ох.. сколько там допущений, лишь бы на нужную скорость выйти...
