Цифровое хранение данных

можно подумать, что на HDD нельзя использовать избыточную информацию. Да, даже проще и она позволит проверять сохранность информации за один запуск команды.

 

Практика показывает, что просто "контролировать" - недостаточно: надо, чтобы сбои вызывали неприятные ощущения. S.M.A.R.T. этого не обеспечивает, "контроль" быстро превращается в ритуал и очень скоро на него забивается болт. "Цирк дедушки Дурова" (действие - подкрепление) куда эффективнее.

А как раз на нём и хорошо появляются неконтакты в шлейфах и интерфейсах контроллер-корпус (от банальных тепловых расширений хотя бы).
Самая ж@па - в том, что сбоями при чтениях это не проявляется, а когда становится заметно ("мусорные" сектора́ в данных - мусор в фильмах, хрип в звуке, "какая-то хрень" в исходниках, кривые CRC в архивах и т.д.) - обычно уже поздно, испорченные файлы уже и на бэкапном носителе давно заняли место нормальных. :-(((((

---------- Сообщение добавлено в 17:58 ---------- Предыдущее сообщение размещено в 17:51 ----------

Конкретно cd-rr и родственные ему (iceecc, par2, recoverystar) на 16-битном Риде-Соломоне - нельзя: слишком малое количество блоков и слишком большой размер блока (зачастую превышающий размер ОЗУ :-( ), плюс изменение каждого блока защищаемых данных должно тут же сопровождаться повторным пересчётом избыточности по всем блокам.
Первую граблю лечит (потенциально, т.к. готовой проги ещё нет) наша с Персиком разработка (её практический предел - миллиард секторов, т.е. полтеры винта или цельный FMD), вторую - RAID 5 (и выше) или встраивание расчёта избыточности "по Персику-Тигре" в драйвер накопителя или файловой системы. Я ж говорю - нужны разработчики-сообщники. :-

 

Offtop

Я занимался помехоустойчивым кодированием, но это было довольно давно. И писать такие вещи на голом ассемблере в наше время... несколько непрактично.

 

Увы, ты не понял. Избыточность не "проверяет", она исправляет. Но специфика БЧХ-кодов (к коим относятся и RS-коды, ЕМНИП) - в том, что для исправления одного битого блока нужны два блока избыточности, если место сбоя неизвестно (плюс редкостно траховычислительноёмкая процедура расчёта локатора ошибки), и всего один блок, если место сбоя известно (т.е. "проверка сохранности" уже выполнена более другими средствами; в простейшем случае - флагом ошибки при чтении сектора).

 

Бывает, что и сразу. Был случай - выключил я компьютер вечером, еще показалось, что какой-то странный звук был при завершении работы. За неделю до этого смотрел смарт - всё было в порядке.

Утром включаю - при загрузке винт издает звон, система не грузится. А потом из него дым пошёл.

 

(рявкает) Ааатставить! (нормальным голосом) Начинка - Си (уже готова; ассемблера там всего с пара десятков строк), обвязка и юзерский интерфейс - пофигу на чём, хоть на яве с пёрлом.

 

Это уже не проблема носителя.

На SATA это проявляется ничуть не хуже.

---------- Сообщение добавлено в 20:12 ---------- Предыдущее сообщение размещено в 20:12 ----------

Ужосы-то какие.

 

О! А с инкрементным БПФом в полях Галуа случайно дела не имел? Тут у меня самый большой затык, собственно на нём всё и заглохло. :-(

 

Рыжий Тигра, имел, но это было в 1998 году. С тех пор я этим не занимался. Надо посмотреть старые архивы, может быть сохранились какие-то исходники. На Турбо Ассемблере писалось, кстати.

 

Ну дык с SATA у меня столько опыта нету. Колись - неконтакт в SATA приводит к тому же эффекту (паразитные единицы в данных и адресах секторов, т.е. запись "не того" "не туда") или винт успевает что-то заподозрить и отказывается выполнять команду записи?

 

Ну начать стоит с того, что в SATA передача данных по кабелю уже идёт с избыточным кодированием (один байт десятью битами).

 

наверно, не понимаю, но почему тогда возможна проверка в ICE ECC (Verify only)?



здесь проверял определенную папку на диске, для которой ранее создал файл восстановления в ICE ECC.
Теперь, испортил данные - удалил один файл, в другом изменил один байт в HEX редакторе. Проводим проверку еще раз:



в результате показано, что некоторые файлы повреждены и все можно восстановить.

 

SubV, будет время и настроение - полистай про cd-rr, а потом вот эту тему. Она заглохла при длительном (несколько месяцев) переезде форума на новый движок, тогда же и погибли вложения. :-( Но у меня остались, за выходные покопаю (и/или в понедельник на работе поищу) и добавлю.

 

Мне крон каждый день присылает отчет, в котором в том числе и состояние hdd от смарта, руками ничего делать не нужно.

Все уже придуманно. Самый популярный вариант на сегодня - zfs. Там и контроль целостности и набор raid'ов на все случаи жизни - от зеркала до raidz3.
Надежно обеспечить востановление данных в случае потери/повреждения можно только с помощью копии. У меня например ценные файлы храняться в 3 экземплярах: zfs set copies=3 uniq_files

p.s. По моему мнению, общая стратегия хранения данных зависит от их ценности и наличия финансов.
Так, если Вы оцениваете данные в сотни $, то второго hdd для зеркала и периодического бакапа куда-нибудь в dropbox достаточно. В случае единиц k$ уже нужен san x 2 на базе той же zfs, с географически разнесенным вторым экземпляром. Для более важных данных существуют аппаратные решения с негуманными ценами.

 

MetroidZ, я это уже расписывал.

Потому что он ориентируется не на секторы, а на блоки своего собственного размера и хранит для них ещё и CRC (а то и MD5). Это помогает против сбоев при передачах (в т.ч. флоппи-нетом или "с проводником") и умышленной порчи, но фигово работает при нечитающихся секторах и вообще отказывает при повреждении заголовков блоков избыточности, в коих и хранятся CRC и разметка на блоки данных. :-(((((

MisterGrim, восстановление одного бита - если это БЧХ-код; если не - только детектирование сбоя (не больше двух бит). Для использования при передаче данных (когда можно переспросить-переповторить) - нормально, для хранения - неприемлемо. :-(

 

ты не понял. С диском то всё в порядке. Он может даже свежезаписаный (или вообще штампованый) и прекрасно читается на том приводе на котором записан (хотя и тут бывают исключения). А вот на другом - может и как диск не опознаваться и не ловиться трек. При этом оба привода исправны и выполняют свои функции. Не вижу, чем тут твоя программа может помочь.

 

Тем более. Даже ритуал становится не нужен. :-(

Увы, нет. Есть способ ещё надёжнее - избыточность в количествах, превышающих кол-во исходных данных. Собственно, в RAID'ах эта фишка тоже применяется, только дорогущая как сарай (аппаратная - по деньгам, программная - по расходу проца).

Т.е. залёт всего трёх секторов - по одному в заголовке каждой копии с одинаковым смещением - и. :-(

 

вообще, вот дураки RAID массивы придумали. Уж давно бы станок, с подкладыванием DVD-R, к сервакам приставили

 

"Прибор гибридный, работает только в комплекте с головой и руками" (L). Чухаться надо было раньше - совместимость приводов проверять до покупки, а не после. :-(

 

Так вот обсуждаемый выше софт — это, по сути, RAID для оптических дисков и есть)