AD>>Не бывает. Как ты себе это представляешь? Если что-то отдает не то, что в него записали, то это не устройство хранения.
vsb>Это устройство хранения, просто некорректно работающее.
Такое устройство выплевывало бы всегда псевдорандом вместо записанных данных, потому что чтобы прочитать данные сектора винту их необходимо вначале декодировать, и именно в этой процедуре вшита процедура проверки целостности с избыточностью для восстановления по возможности. Не удалось декодировать — возвращаем ошибку и добавляем сектор в relocation list. Удалось — все ок. Если декодирование не работает адекватно — на верх будет вылазить мусор вообще всегда, потому что на фих уровне данные хранятся совсем иные. Если работает — просто смотрим смарт и заменяем накопитель когда появляется хоть один relocation event. Протоколы передачи SATA так же покрыты контрольными суммами статистика по ошибка мкоторых опять же контролируются смартом. Но нет, давайте все хэшировать еще раз, ведь это просто и термин "целостность данных" понятен даже менеджерам среднего звена. Хотя по сути хэшировать хэшированное — это профанация идеи целостности данных, которое в долгосрочной перспективе может быть опасно, т.к. вызовет у разработчиков приложений ложной чувство безопасности и они перестанут покрывать контрольными суммамии реально критичные данные, и тут то и полезут реальные проблемы, типа битого бита в надцатом чипе SDRAM, которое пожалуй единственное устройства хранения данных или не покрытое ECC или, в случае серверов — покрытое, но очень слабым кодом четности. А от проблем с памятью защититься можно только хэшированием со стороны приложения, а не FS.

AD>>Не бывает. Как ты себе это представляешь? Если что-то отдает не то, что в него записали, то это не устройство хранения.
vsb>Это устройство хранения, просто некорректно работающее.
Такое устройство выплевывало бы всегда псевдорандом вместо записанных данных, потому что чтобы прочитать данные сектора винту их необходимо вначале декодировать, и именно в этой процедуре вшита процедура проверки целостности с избыточностью для восстановления по возможности. Не удалось декодировать — возвращаем ошибку и добавляем сектор в relocation list. Удалось — все ок. Если декодирование не работает адекватно — на верх будет вылазить мусор вообще всегда, потому что на фих уровне данные хранятся совсем иные. Если работает — просто смотрим смарт и заменяем накопитель когда появляется хоть один relocation event. Протоколы передачи SATA так же покрыты контрольными суммами статистика по ошибка мкоторых опять же контролируются смартом. Но нет, давайте все хэшировать еще раз, ведь это просто, молодежно да и термин "целостность данных" понятен даже менеджерам среднего звена. Хотя по сути хэшировать хэшированное — это профанация идеи целостности данных, что в долгосрочной перспективе может быть опасно, т.к. вызовет у разработчиков приложений ложное чувство безопасности и они перестанут покрывать контрольными суммамии реально критичные данные, и тут то и полезут реальные проблемы, типа битого бита в надцатом чипе SDRAM, которое пожалуй единственное устройство хранения данных или не покрытое ECC или, в случае серверов — покрытое, но очень слабым кодом четности. А от проблем с памятью защититься можно только хэшированием со стороны приложения, а не FS.