CK>>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE.
CK>>google -> "RAID5 URE"
S>Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.

http://dl.acm.org/citation.cfm?id=1416947&CFID=801395650&CFTOKEN=85226457

2.3 Corruption Classes
This study focuses on disk block corruptions caused by both hardware and
software errors. Hardware bugs include bugs in the disk drive or the disk
shelf firmware, bad memory, and adapter failures. Software bugs could also
cause some corruption. In many cases, the cause of corruption cannot be
identified. We detect different forms of corruption using the different data
protection mechanisms in place. As mentioned earlier, we distinguish be-
tween these forms in our study. Table I gives a summary of these corruption
classes.
—
Checksum Mismatches (CMs). This corruption class refers to cases where the
corruption is detected from mismatched data and checksum. The cause could
be: (i) data content corrupted by components within the data path; (ii) a torn
write, wherein only a portion of the data block is written successfully; or (iii)
a misdirected write, wherein the data is written to either the wrong disk or
the wrong location on disk, thus overwriting and corrupting data [Bartlett
and Spainhower 2004; Prabhakaran et al. 2005]. Checksum mismatches can
be detected anytime a disk block is read (file system reads, data scrubs, RAID
reconstruction, and so on).
—
Identity Discrepancies (IDs). This corruption class refers to a mismatch de-
tected when a disk block identity check is performed during a file system
read. The cause could be: (i) a lost write, which typically occurs because a
write destined for disk is not written but thought of as written; or (ii) a mis-
directed write, where the original disk location is not updated. We are aware
of actual cases when the disk firmware replied successfully to a write that
ACM Transactions on Storage, Vol. 4, No. 3, Article 8, Publication date: November 2008.
An Analysis of Data Corruption in the Storage Stack was never written to stable media.
Identity discrepancies can be detected only during file system reads.
—
Parity Inconsistencies (PIs): This corruption class refers to a mismatch be-
tween the parity computed from data blocks and the parity stored on disk
despite the individual checksums being valid. This error could be caused
by lost or misdirected writes, in-memory corruptions, processor miscalcula-
tions, and software bugs. Parity inconsistencies are detected only during data
scrub

S>CAP — вообще булшит, простите за прямоту. "Научные" работы, которые оперируют термином Availability в смысле "она есть либо нету", нужно сразу скармливать в шредер.
S>Нормальные инженеры оперируют процентом аптайма. Реальные системы никогда не смогут получить 100% аптайм. Для понимания этого не надо защищать докторские диссертации или доказывать теоремы.

Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд.

S>Инженерам формальное доказательство тезиса "железу свойственно ломаться" неинтересно. Инженерам интересно, как получить систему с availability = 99.99% из компонентов с availability = 99%.
S>Именно поэтому все рассуждения про построение HA без обсуждения time to recover — булшит и профанация.
S>В частности, в CAP про это нету ничего, кроме упоминания во введении. В стиле "но, поскольку это слишком сложно, то в данной работе заниматься этим мы не будем".

Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости. Какое отношение к этому имеют твои 99.99% аптайма — тайна покрытая мраком. Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. А CAP как раз про гарантию возможности сделать что-либо. Если система не линеаризуема, то ни какой аптайм не даст тебе возможность получить целостную картину данных в любой момент времени. Как-то так.

S>Конечно слышал. Делать вид, что standby оборудование не является частью вашей HA-конфигурации — опять профанация.
S>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.

Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так

S>Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.

В "ЕС2-стиле" это когда spot инстансы автоматически provision-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен? Ну да, действительно не очень актуально

CK>>Я же написал как. CRC защищает от небольших повреждений (bit flip). В этом случае контроллер может попереворачивать биты сверяя CRC, но этот процесс не гарантирует ничего на 100%. Как минимум, может повредиться сама контрольная сумма. Как максимум — несколько повреждений в одном секторе гарантированно приведут к URE.
CK>>google -> "RAID5 URE"
S>Какое отношение URE имеют к прочтению побитых данных? Вы путаете CRC с ECC.

http://dl.acm.org/citation.cfm?id=1416947&CFID=801395650&CFTOKEN=85226457

2.3 Corruption Classes
This study focuses on disk block corruptions caused by both hardware and
software errors. Hardware bugs include bugs in the disk drive or the disk
shelf firmware, bad memory, and adapter failures. Software bugs could also
cause some corruption. In many cases, the cause of corruption cannot be
identified. We detect different forms of corruption using the different data
protection mechanisms in place. As mentioned earlier, we distinguish be-
tween these forms in our study. Table I gives a summary of these corruption
classes.
—
Checksum Mismatches (CMs). This corruption class refers to cases where the
corruption is detected from mismatched data and checksum. The cause could
be: (i) data content corrupted by components within the data path; (ii) a torn
write, wherein only a portion of the data block is written successfully; or (iii)
a misdirected write, wherein the data is written to either the wrong disk or
the wrong location on disk, thus overwriting and corrupting data [Bartlett
and Spainhower 2004; Prabhakaran et al. 2005]. Checksum mismatches can
be detected anytime a disk block is read (file system reads, data scrubs, RAID
reconstruction, and so on).
—
Identity Discrepancies (IDs). This corruption class refers to a mismatch de-
tected when a disk block identity check is performed during a file system
read. The cause could be: (i) a lost write, which typically occurs because a
write destined for disk is not written but thought of as written; or (ii) a mis-
directed write, where the original disk location is not updated. We are aware
of actual cases when the disk firmware replied successfully to a write that
ACM Transactions on Storage, Vol. 4, No. 3, Article 8, Publication date: November 2008.
An Analysis of Data Corruption in the Storage Stack was never written to stable media.
Identity discrepancies can be detected only during file system reads.
—
Parity Inconsistencies (PIs): This corruption class refers to a mismatch be-
tween the parity computed from data blocks and the parity stored on disk
despite the individual checksums being valid. This error could be caused
by lost or misdirected writes, in-memory corruptions, processor miscalcula-
tions, and software bugs. Parity inconsistencies are detected only during data
scrub

S>CAP — вообще булшит, простите за прямоту. "Научные" работы, которые оперируют термином Availability в смысле "она есть либо нету", нужно сразу скармливать в шредер.
S>Нормальные инженеры оперируют процентом аптайма. Реальные системы никогда не смогут получить 100% аптайм. Для понимания этого не надо защищать докторские диссертации или доказывать теоремы.

Инженерам следовало бы прочитать и разобрать хоть одну научную статью на эту тему. В CAP не ведется речь ни о каких реальных системах, там в качестве хранилища используется один регистр, вместо сети — асинхронная модель сети и тд.

S>Инженерам формальное доказательство тезиса "железу свойственно ломаться" неинтересно. Инженерам интересно, как получить систему с availability = 99.99% из компонентов с availability = 99%.
S>Именно поэтому все рассуждения про построение HA без обсуждения time to recover — булшит и профанация.
S>В частности, в CAP про это нету ничего, кроме упоминания во введении. В стиле "но, поскольку это слишком сложно, то в данной работе заниматься этим мы не будем".

Наверное потому что CAP вообще не про это. Обычно с ее помощью рассуждают о линеаризуемости. Какое отношение к этому имеют твои 99.99% аптайма — тайна покрытая мраком. Можно иметь 100% аптайм, но не иметь возможности получить или записать данные. А CAP как раз про гарантию возможности сделать что-либо. Если система не линеаризуема, то никакой аптайм не даст тебе возможность получить целостную картину данных в любой момент времени. Как-то так.

S>Конечно слышал. Делать вид, что standby оборудование не является частью вашей HA-конфигурации — опять профанация.
S>То есть если у вас трёхмашинный HA-кластер, и есть четвёртая машина в hot standby, то у вас четырёхмашинная конфигурация. И точно так же, при единичном сбое, она превращается в "обычную" HA-конфигурацию, которая точно такая же, только без hot standby.

Не буду спорить, мне кажется, в мире абсолютно надежных жестких дисков все действительно может быть так

S>Более того, hot standby уменьшит MTTR только на время подготовки новой машины. Это актуально, если ваши процессы ввода в эксплуатацию построены на заказе сервера в Dell и его физической доставке и установке. Если у вас процесс ввода новой машинки в эксплуатацию построен на EC2-стиле, а сами машинки — stateful, то MTTR будет определяться временем репликации данных, и использование hot standby будет противопоказано.

В "ЕС2-стиле" это когда spot инстансы автоматически provision-ятся самим приложением на основе текущей нагрузки, прогноза и текущих цен? Ну да, действительно не очень актуально