две CRC вычесленные по разным алгоритмам дают меньшую битность чем одно CRC с большой битностью> И косвенно обе половинки друг-друга верифицируют. Если результаты обсчета блока данных совпали для обех
давайте только вот не будем излагать всё это на пальцах, в своём каком-то там особенном понимании
> получили исправный блок данных с CRC повышенной длины.
повышенной на сколько бит?
> Совпали только для одной, значит с приличной вероятностью вторая CRC посчиталась неверно, а блок данных не при чем.
с какого это хера вы делаете такие выводы? Если где-то что-то не срослось, то значит что запорчено всё, и блок данных, и сами суммы.
Существуют специальные пары контрольных сумм, которые помогают узнать где примерно произошла порча при условии что может побиться не более заранее указанного числа бит. Такие методы обычно используются для коррекции медийных ошибок чтения/записи/передачи где можно построить вероятностную модель ошибки. И это, кстати, не CRC методы.
А CRC в топике выше преследует иную цель - детектирование порчи данных по "техногенной" причине. Наример, вообще не тот сектор оказался где ожидается inode (такое, например, может быть если улетела карта отображений менеджера томов) или горе-админ решил что-то как-то пофиксить и сломал всё.
Т.е. алгоритм анализа CRC совсем другой - если оно не совпрало, значит произошла порча и нельзя сказать как и где. Это просто сигнал для более детального анализа (человеком или эвристическими методами).
А если CRC совпала то это не значит ничего, т.е. это не означает целостности данных и даже нельзя сказать с какой вероятностью они оказались валидными.
Это всё сказано применительно к CRC метаданных в ФС.
Кстати, там где-то ниже, или выше, разгорелся срач на эту тему и какой-то чувак всё упорно не видит различия между видами "контрольных сумм" (т.е. коррекция медийных ошибок с детерминированной моделью ошибки и защита от условно умышленной порчи где в принципе нельзя построить модель) и беды от которых они могут защитить.
