Надёжность флопиков и RAW NAND

> И может ведь получиться так, что именно этот дополнительный 22 сектор не запишется, поэтому при попытке восcтановления получится непонятно что.

Это уже отказ двух секторов: 22 и какого-то ещё. А я сразу оговариваю, что допустим отказ только одного сектора.

> Так вот, недостаток этого алгоритма в том, что если ошибок нечетное число, то он их видит.

Я не предлагаю отказываться от уже имеющегося контроля CRC. Сектор 22 и XOR'ка по всем секторам нужны только для восстановления, в случае разрушения одного из секторов. Т.е. при записи пересчитывается и перезаписывается 22-й сектор, а при чтении, если стандартная CRC по всем запрошенным секторам совпала без ошибок, то 22-й сектор можно и не читать.

> Но не совсем понято, что дальше с этим делать.

Я тут решаю две, мало связанных друг с другом задачи. 22-й сектор - это защита по всем трекам. А многократный повтор нулевого сектора - это защита именно нулевого трека с учётом того, что ROM loader не умеет восстанавливать данные по схеме с 22 секторами и ему нужна понятная для него структура данных.

Т.е. одним способом защищается нулевой трек и другим - остальные.

> И так пока всю коробку с загрузочными дисками не переберешь :)

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

> Еще проблема - если программа не пользуется файлами, а пишет данные через RWTS. В случае сбоя она может так файловую систему разнести, что никакие резервные сектора не спасут.

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

Из того, что вспоминается, стоящее особняком: только LODE RUNNER имел большой прямо адресуемый кусок диска с уровнями. И ещё PUSHER читал свой PUSHER.LEVELS через собственный драйвер файловой системы.

--

Ещё интересный вопрос: а если снижать битрейт контроллера, насколько это будет повышать надёжность ?
По PC-шному опыту: иногда, хорошие дискеты на 800 Кб имели меньшую вероятность ошибок, чем на 1.2 Мб (на том же дисководе). Но не всегда. Только с одной маркой дискет (красные Sigma) удавалось на 800 Кб не иметь вообще ни одного сбоя на коробку дисков. Остальные (ИЗОТ и прочее) даже на низкой плотности давали 1-2 сектора со сбоями на диск. Но и высокоплотные TDK, например, давали те же 1-2 сбойных сектора на диск.

Получается, что TDK были выгоднее - общий объём больше, потери - те же.

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

Бороться с отдельными сбоями нескольких секторов на PC было довольно легко: я использовал прогу-тестилку, которая ловила такие сектора и блокировала их. Её отличие от всяких NDD и прочего было в том, что она ловила сектора по отдельному сбою, без попыток их перечтения. Поэтому поиск шел бодро и давал надёжный результат.

--

Подобная же тестилка на Агате тоже хорошо помогала.
Интересно что сейчас (когда искал исходники "Президента") пробовал читать свои старые диски с отмеченными сбойными секторами. И Мост3 вычитывал их без особых проблем, включая сектора, отмеченные как "сбойные".

--

Интересно, а если отключить голову дисковода от штатного усилителя-формирователя и зацепить её на какой нибудь усилок + однобитный АЦП (просто компаратор, который возвращает 1 при положительной полуволне и 0 при отрицательной), не позволит ли это ещё приподнять качество чтения ? Или может быть использовать двух или трех битный АЦП .... Есть ли тут какие-то дополнительные возможности ?

> Все эти идеи по повышению надёжности работы дисководов - это какие-то планы для дальнейшего внедрения или просто размышления?

Больше теория. Поэтому и раздел выбран "Прочее...", а не специализированный по дисководам.
Её можно было бы попробовать внедрить, но есть ещё много другого интересного, что тоже хотелось бы сделать.

> А какая-нибудь статистика есть? Сколько обычно бывает сбойных секторов на один трек на Агатовских дисках?

У меня почти нет статистики по обычному использованию 840ок, но то, что я видел с мостами: одиночные ошибки легко возможны, но и множественные тоже. Но когда начинают сыпаться множественные, то это нередко будет по значительной части диска. Например, по 2-3 сектора на каждой дорожке. (Причем даже номера секторов будут иметь какую-то регулярность, как будто царапина по поверхности. Если я вижу такой образ, то обычно спрашиваю у Игоря, нет ли явных механических повреждений на диске ? Иногда бывает, но иногда в явном виде их нет.)
Или множественные на конкретном дисководе. Ставим диск на другой - там проблем резко меньше.

На 140ках ошибки были трёх типов:
- 1-2 сбойных сектора на случайном треке.
- массовые (больше половины секторов) на последних треках (примерно от 30-го с плавным нарастанием): 29 - 2, 30 - 4-6, 31 - 5-8; 32 - 10; 33 - 13; 34 - 15. Это стало проявляться по мере износа головы.
- странный баг на 17-й дорожке: часто бывает повреждён сектор 7. Скорее всего, это какая-то программная ошибка, но может быть и нестабильность скорости привода (этот сектор затирается при перезаписи VTOC - нулевого сектора).

{
  К слову, на PC обычно бывало 1-2 ошибки на трек, но на редких треках. Исключение: нулевая дорога, два сбойных сектора вполне было нормой. Видимо из-за того, что там головка проводит значительную часть времени, читая и переписывая FAT.
}

Т.е. в идеале надо быть готовым к 2 ошибкам на треке. Это хорошо будет закрывать случаи исправной и юстированной аппаратуры. При этом можно расчитывать, что много соседних треков вообще не будут иметь ошибок. Поэтому, если бы хватало вычислительных мощностей и ОЗУ, можно было бы объединять 2-4 несоседних трека в группы для синтеза избыточных данных. Но это уже заметно завалит скорость работы: для расчёта каждой группы придётся либо иметь копию всех треков группы в ОЗУ или перечитывать нужные треки. Тут уже пахнет каким-то дисковым кешем, хотя бы небольшого размера и связанным с этим требованием иметь сигнал Disk Change.

> Тут сразу непонятка, ведь Агатовский контроллер битрейт снижать не позволяет? Или мы чисто теорию обсуждаем?

Теория. Но источник тактовой частоты только один, так что воткнуть по ходу движения делитель выглядит не очень сложной задачей. Либо пристроить какой-то внешний, может быть регулируемый, генератор.
Это более сложно для 140ки, из-за её синхронизма с ЦП и заметно попроще на 840ке.

> дискет разный материал магнитного слоя

Это я знаю. И везде, где описываю разные ёмкости, речь идёт именно о дисках, соответствующих битрейту и режимам записи. Если про PC.

Про Агат, причем с дисками 3.5'':

> Если наоборот, HD-шный диск записывать на 800 Кб дисководе, то ему ток записи будет мал и при чтении вырастет уровень шумов. То есть, ошибок тоже будет больше.

Тут вот какое наблюдение: дисков 3.5'' на DD у меня почти нет. Но есть много HD. Они неплохо работают на низком битрейте с агатовским контроллером если заклеить окошко плотности. Я бы сказал так, что именно с Агатом в таком режиме эти диски работают даже лучше, чем с PC. Ошибки бывают, но довольно стабильные по размещению, похожие на износ поверхности. Диски совсем не новые.

И как тут объяснить несоответствие плотности записи материалу поверхности - не знаю.

Вообще, сама теория вроде бы понятна, но ведь спектры HD и DD записи значительно перекрываются: 1-2-3 мкс и 2-4-8 мкс. Возможно, шумы тут меняются не очень существенно. Да и, как помнится, DD-диск 5.25'' можно было отформатировать в HD, хотя, наверное, уровень ошибок возрастал. Но у меня статистики тут нет.