> Нифига он не сообщит - если удалось починить то вы получаете данные. Если не удалось - read error. Статистика полетов - в SMART.И что вам не понравилось, будет ошибка - сообщит, будет исправимая ошибка - не сообщит. В чем проблема? Или Вам надо по каждой проблеме свой лог вести, даже если проблема и не проблема вовсе?
На счет работы ЖД я в курсе. Ремап можно запустить многократной записью в сектор с большим временем доступа. Предполагаю, что с некоторыми конкретными моделями есть нюансы, но это не суть важно.
> Ничто не мешает, кроме того что ФС это может делать прозрачно и для всего,
> а в остальных случаях - надо явно позаботиться.
dalco уже говорил, что в случае ZFS/BTRFS по диску проходит демон и проверяет CRC. Точно такого же демона (по сути, это та же программа или, с определенной натяжкой в деталях реализации, скрипт) можно сделать универсальным для всех ФС. Так зачем делать из кода поддержки ФС кухонный комбайн и жить в ожидании что какая-нибудь из тех встроенных хреновин, без которых "нельзя" прожить, не "накроет" всю информацию на винте? Из практических соображений критические области, коей по факту важности и является ФС, необходимо уменьшать и упрощать, а тут предлагают сделать разжиревшее и потенциально небезопасное с точки зрения хранения информации, мягко говоря, уродство.
Ошибки надо исправлять на том уровне, на котором их возможно в наиболее полной мере исправить. Это возможно при обладании максимально полной информацией о том, чего Вы хотите. ФС этого знать не может. Можно конечно сделать механизм, позволяющей сделать это, но надо ли это все, если вполне реально обеспечить ту же функциональность другими, более универсальными, а скорее всего и не мене (если не более) эффективными средствами, в наибольшей степени отвечающим вашим потребностям. Именно по этому CRC метаданных - есть правильное решение т.к. кроме ФС, владеющей ими, о них толком ни кто не знает (и не должен) и решения должны приниматься именно на этом уровне. В случае же с данными пользователя, они принадлежат именно ему, а не ФС, именно по этому решения по их обслуживанию и само обслуживание должно приниматься и производиться им, конечно при условии, что его интересы не настолько жестко завязаны на конкретную ФС и не требуют проведения специфичных операций. В случае CRC данных пользователя никаких специфичных операций производиться не должно.
> постоянном их изменении как в случае с БД, просчитать CRC вообще
> будет невозможно, либо возможно, но с большими потерями ресурсов системы.
> Что за идиотека? Кто запретил считать CRC поблочно?
И как посчитать CRC БД так, чтобы им можно было воспользоваться, при условии, что БД все же используется, а не просто хранится? Подсказка: конечная цель всей этой "камасутры" не посчитать CRC, а установить корректность и неизменность данных, что без привлечения самой СУБД с этой БД невозможно в принципе. Даже если ФС позволяет "заморозить" данные для расчета CRC, то установить момент для "заморозки", когда дынные в БД будут в валидном состоянии, без самой СУБД невозможно. Связь же между СУБД и ФС, которая могла бы включать такую возможность, вообще маразм высшей степени.
