Полигон-2

i8088 написал:

[q]

А что за чипсет в Вашей рабочей станции?

[/q]

VIA 82C686B. Перепаять, что ли? На работе паяльная станция есть. Или материнку сменить? У меня несколько материнок на S370 с ISA, но каждая с каким-нибудь брачком...

На работе прогнал график чтения для восстановленного 7200.7 с прошивкой 8.54


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

До кучи, график с восстановленного 7200.9, тоже на 80 Гб


Плотность выросла ровно вдвое, а скорость линейного чтения - даже меньше чем в √2 раза, с 56 до 72 Мбит/с.

Да, небольшой хинт: чтобы график был без ложных провалов, а компьютером параллельно можно было пользоваться, надо задать процессу Victoria приоритет realtime.

wrenchrox написал:

[q]

Оченно хотелось бы почитать часть опуса про Samsung-и!

[/q]

Окей, ближайшее время займусь.

KALDYH, вопросы по отправке cert (в данном случае для TONKA40).

В Вашем примере для TONKA2

[q]

CREATE_FILE/track\cert1.bin/track\cert.bin/1/0/280/1
CREATE_FILE/track\cert2.bin/track\cert.bin/0/0/188/1

Скрипт сливает два файла в один (cert.bin), беря 280h секторов из cert1.bin и 188h из cert2.bin.

Для его посылки и запуска используется скрипт следующего вида (пример для TONKA2 - длина серта 520h секторов):

SPEED/115200
STR/d,3,1/0
SLEEP/4000
SEND_FILE/4096/track\Cert.bin/>0/>520
STR/r/0
BAUDRATE/9600

[/q]

Почему при объединении cert1 и cert2 280h + 188h получаем 520h, а не 408h?
А можно ли просто соединить cert1 и cert2, и записать 500h секторов?


Для моего TONKA40 я получил:

1>r

cmd  58,  params  0032 0000 0000 0408 0B80 0408 0000 0000 000A 6201 0032
DiskAccess ReadSector EC=43 at ffffffff.00.0000

cmd  58,  params  0032 0000 0000 0408 0B80 0408 0000 0000 000A 6201 0032
DiskAccess ReadSector EC=43 at ffffffff.00.0000
INVALID Cert Disk Code - ROM Resident Revision Required: 2AAAQ0
    Code - 70  Track FFFFF(0B9DE).0.000  Sns 000  Rty F7FF.24.80FF  Rtf 1800  LBA 00000037
1>


Те, трек с CERT 0x32, а длина 0x408, как в таблице offsets.xls.

В таблице offset.xls для cert1/cert2 TONKA40 указано 2FDh 10Bh, но по ссылке: http://files.hddguru.com/downl...e/Tonka40/
Cert1 заполнен полностью, а у cert2 нулевые байты начинаются с адреса 26800h, те длина 134h?
Как тогда правильно сделать cert для отправки, и какую длину записывать?

И еще, где в той ссылке cert tables?

OK, спасибо за разъяснения!

Диск с Win2000 и ST_MEM сейчас отключен, да и для лучшего понимания процесса (тк
рассматривается идея написания новой программы) уточню по ручному получению файлов
для отправки в накопитель (один из множества вариантов):

1. У TONKA40, в отличие от TONKA2, cert_1 больше 1 трека, зато cert_2 меньше, суммарная же
длина cert-а не изменилась.

2. Для получения cert-а, пригодного для отправки по SDLD, достаточно например соединить оба
трека в один файл, и отрезать (в отдельный файл, для будущего получеия cert tables) все что
начинается с сектора 408h (81000h). Можно и не отрезать, а просто отправить 408h секторов
в накопитель из объединенного файла.

3. Отрезанная часть (начало бывшего 10bh) будет содержать 2 шт cert table, и байты заполнители.
Из этого вырезаем первую из cert table (можно и не вырезать, а просто переставить сектора), и
меняем местами 0 и 17 сектор, те перемещаем первые 512 байт в конец файла. И отправляем 18h
секторов в накопитель.

4. А что делать со второй табличкой? Насколько я понял из приведенного Вами скрипта,
переставляются сектора в первой таблице, и отправляется 18 секторов.

5. Можно в принципе просто записать имеющиеся треки по известным смещениям от начала SA,
но это менее корректно, и уже без использования SDLD будет медленнее.

Правильно ли я понял?

upd.
Эта перестановка секторов в cert tables, есть у всех Barracuda, или начиная с какого-то семейства?

Спасибо за разъяснения!! Продолжу ковыряться.