> К сожалению, нет гарантии, что на винте записаны те самые данные, что
> мы хотели записать. В реальной жизни то шлейф к винту барахлит,
> то питание моргает, то память сбоит, то ОС вразнос пошла. А
> на винте его внутренние CRC при таких неисправностях вполне правильные -
> он же не в курсе, что ему мусор для записи передали
> :) Вот для подобных случаев дополнительная CRC на уровне файловой системы
> и выше становится полезна.Ошибки интерфейса отлавливаются точно (см. SMART). Буферная память ЖД также может быть проверена (MHDD, Victoria). Питание, уж извините, ИБП решает. Память тоже с избыточностью бывает, вплоть до восстановления информации "на лету". ОС оно конечно серьезно, но такого уровня компоненты, работающие внутри ядра, должны и скорее всего усиленно тестируются. Не надо также забывать и о проверке "временем", т.е. пользоваться не самым новым, а зарекомендовавшим себя ядром/софтом/железом там , где нужна повышенная надежность. Делайте копии, профилактику и будет счастье.
> Кстати, там еще и некоторый бонус всплывает - после сбоя проще повреждения
> искать. Где CRC нарушено - там точно усиленные раскопки нужны.
Никак не проще. Постройте себе дерево из CRC для интересующей части ФС и сверяйте ее с текущим. Вот и все.
> P.S. А если еще и данные в файловой системе CRC прикрыты, то
> вообще красота. При периодической фоновой проверке я не только узнаю о
> наличии проблем, но я еще и буду точно знать - какие
> конкретно файлы накрылись медным тазом, что, зачастую, крайне полезно при реанимации
> зомби-компа.
Если "зачастую крайне полезно", то у Вас уже есть примеры реализации подобных возможностей. Если не сложно поделиться инфой, поделитесь.
Делая своевременные копии информации мне все равно что случится с компом и я всегда уверен, что если выяснится факт некорректности файла - я смогу взять его из проверенной копии.
Все проблемы решаемы, и не надо придумывать себе задачи, которые кроме как к новым проблемам ни к чему не приведут, и их решать.
