Во-первых, спасибо за детали работы, не знал, хоть к делу это и не имеет отношения.Во-вторых, процетирую dalco:
> Чтобы обнаруживать сбои накопителей или линков к ним, например. В момент
> их появления, а не когда половина файловой системы превратится в какие-то макароны.
и после моего коммента (он же):
> К сожалению, нет гарантии, что на винте записаны те самые данные, что мы хотели записать.
Так что то, что я имел ввиду я ввиду и имел, что подтверждаете и Вы
> Только если после M попыток так и не удалось считать блок, то получается ошибка IO.
т.к. потеря доли информации из-за неудачного чтения эквивалентно ее испорченному состоянию.
> сумма на диске служит совсем иным целям.
Это да, но также она гарантирует и то, что данные считанные с диска - это те же данные, что на него и записывались.
Тут же, усиленно предлагают, и за это неистово "плюсуют", ввести второй уровень проверки корректности данных на диске исходя из того, что эта гарантия не работает, причем встроить эту проверку в код работы ФС.
Единственное, для чего это может пригодиться, так это для аудита системы и проверки того, что никто не изменил данные извне. Но это вообще к ФС отношения не имеет и в код включаться не должно. Также тут упоминается про ZFS и BTRFS, в которых, со слов того же dalco, имеется встроенная возможность проверки контрольных сумм файлов в ФС. Правда он заметил, что она реализована через демон и работает на уровне ядра (тут у меня есть некоторые сомнения, но разбираться не хочу за ненадобностью).
Мной предлагался способ считать контрольные суммы без участия ФС, что я считаю как минимум более логичным.
