Полигон-2

Продолжаю изучать SCSI контроллеры.
Вернулся ко мне мой винчестер Maxtor 120Мб, и с ним я понял что все мои 5 контроллеров исправны, что терминация не влияет на "видимость" и читаемость винчестеров. Но сейчас я хотел спросить о совместимости. Вот у MFM 8 бит были семейства, между которыми не было никакой совместимости в записи данных на винт, и контроллер из другого семейства не видел инфу на винчестере, записанным на контроллере иного семейства. В SCSI я обнаружил нечто похожее. Это известный факт или у меня что-то не так?
Контроллеры:
1. VLSI Future Domain-850 8бит.
2. DTC-3150 8бит
3. DTC-3280 16бит

4. Adaptec AHA-1520B 16 бит
5. Storage Dimensions SDC-801 8 бит

Первые три - это "Группа1". Винт, отформатированный на любом из них, полноценно читается на других из этой группы.
При этом на п.4 винчестер не грузится (Missing Operation System), но все данные видятся, партиция видится. И наоборот.
П.5. живет своей жизнью. Он то портит данные, то не видит созданную им же партицию. До меня вдруг дошло, что может 386SX-40 слишком быстрая машина для него. Я убрал Turbo, и глюков стало меньше. Сейчас воткнул его в ХТ 12МГц, глюки ушли совсем. Теперь считаем этот контроллер "одомашненным", т.е. рабочим и безглючным. Так вот, он не увидел партиции и вообще какие-либо данные после форматирования винта в группе1. А вот его форматирование столь суровое, что после него группа1 разделилась: контроллер 1 ничего не увидел на винте, причем fdisk заявил: "Error reading fixing disk", и никакими хитростями мне не удалось реанимировать винт с этим контроллером. А вот контроллер 2 данные увидел, но Non system Disk. После него контроллер 1 снова ничего не увидел, а fdisk снова выругался, т.е. данные-то есть, но на винт, как будто легло проклятье, настроенное на контроллер 1. После форматирования контроллером 2 винт снова увиделся в контроллере 1, проклятье ушло, но для контроллера 5 винт стал чистым.

1. Почему такое явление? Почему чаще всего не видится загрузочная запись другим контроллером, а реже вообще все данные?
2. Если у меня не видится загрузочная запись, т.е. винт не грузится, но содержимое диска отображается командой DIR после загрузки с дискеты, то могу ли я быть уверенным в корректности данных: все ли каталоги отображаются, все ли файлы корректные? И тогда достаточно ли мне запустить SYS и сделать винт снова загрузочным?
3. Как может частота процессора влиять на п.5? Я бы понял, если бы влияла частота шины, но она ведь фиксированная: 14,318/2 МГц. А процессор лишь быстрее или медленнее выполняет инструкции из BIOS-а.

Я так и подумал, но полагал, что такое было только у ранних IDE до изобретения авто-детекта году этак в 89-90м.
Значит, если у пользователя согрел контроллер, то данным хана, либо искать такой же...
Дядька alecv, а напомни мне по моему вопросу 2 на счет SYS?

На IDE мне помогал перенос системы сделать винт загрузочным без потери данных

sanders написал:

[q]

могу ли я быть уверенным в корректности данных: все ли каталоги отображаются, все ли файлы корректные?

[/q]

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

Подключи параллельно второй винч и скопируй на него часть файлов/каталогов с винча повреждённого. Если копии файлов явно набиты галиматьёй, значит тест провален. В сём случае операции записи на повреждённый винч отсутствуют.

Способ переноса без потерь уже озвучил alecv.

По вопросу #3, конечно влияет. На скорость обращения к диску. Но на "низкий" уровень биос контроллера всё-равно запрос от ОС не пустит. Так что "затык" будет только со стороны процессора. Если произойдёт ситуация описанная вами - это говорит только о неисправности контроллера или ошибках в его биосе, либо проблеме с интерфейсным кабелем.