ODS1 FILES-11 DECFILES11A reader

[anasana]

Причёсывая извлекалку добрался до рефакторинга вывода списка "плохих" блоков на томе, ну и реальный дамп у себя отыскал у которого "не всё чисто", подходящий для тестов.
В мануале DEC Files-11_ODS-1_Spec раздела описания badblk.sys указана особая структура всегда размером 512 байт (1 сектор что для дискеты, что для огромных жестких дисков), расположенная в самом последнем живом секторе на диске, тут, если с нуля, - 799 или же он же 800-й (размер дискеты 409600 байт)

"Virtual block 1 of the bad block file is the bad block descriptor for the volume.
It is always located on the last good block of the volume.
...
This block is included in the bad block file to save the data it contains for future re-initializations of the volume."

где есть поле о количестве плохих секторов диска, (здесь их было заявлено: 3)
и далее перечислением идёт их типа список (max. 126 шт.):
List of volume bad blocks (showed LBN's marked as damaged):
777, 780, 788
end
и в конце поле контрольной суммы (badmh B_CHK1).

В базе файл-карты занятых полезными данными секторов (bitmap.sys) это выглядит вот так:

Map of used blocks (showed LBN's marked as free):
(начало диска, обычно сектора плотно зазаняты)
   ,    ,    ,    ,    ,    ,    ,    ,    ,    , 
...
(и под конец чаще уже посвободнее)
760, 761, 762, 763, 764, 765, 766, 767, 768, 769, 
770, 771, 772, 773, 774, 775, 776,    , 778, 779, 
   ,    ,    , 783, 784, 785, 786, 787,    , 789, 
790, 791, 792, 793, 794, 795, 796, 797, 798,    ,
end

логично, что указанные "несвободные" damaged 777, 780, 788 - запрещено использовать т.к. они "плохие", ну и последний 799 в нём о них инфа и хранится.

а теперь внимательно смотрим за руками:
собственно заголовок самого файла badblk.sys этой дискеты хранит список указателей на приналдежащие ему, как любому обычному файлу, сектора
Filename: [1,1] badblk .sys;1 ;0 #№ 3 lifetime seq: 3, 1stLBN:(5:777) [RWED,RWED,RWED,RWED] Rev.date: Rev.time: Creat.date: 30JAN92 Creat.time: 154512 Expirat.date:
filnum H_CKSM: 3D83 - OK
filnum 3 exsist
Fileitem nullsized
Segment 1. Chunk LBN's: 777 (512 bytes at last) | 777, higblk: 0, eofblk: 0, vbncounter: 1
Segment 2. Chunk LBN's: 780 781 782 (512 bytes at last) | 782, higblk: 0, eofblk: 0, vbncounter: 4
Segment 3. Chunk LBN's: 788 (512 bytes at last) | 788, higblk: 0, eofblk: 0, vbncounter: 5
Segment 4. Chunk LBN's: 799 (512 bytes at last) | 799, higblk: 0, eofblk: 0, vbncounter: 6
badmh B_CHK1: 0A30 - OK

т.е. badblk.sys "храня в себе" "замыкает на себя" (сбойные?) сектора дискеты 777 780 781 782 788 и, собс-но, инфо-тело со структурой, в 799

Map of used blocks (showed LBN's marked as free):
   ,    ,    ,    ,    ,    ,    ,    ,    ,    , 
...
770, 771, 772, 773, 774, 775, 776, BAD, 778, 779, 
BAD, BAD, BAD, 783, 784, 785, 786, 787, BAD, 789, 
790, 791, 792, 793, 794, 795, 796, 797, 798,    , 
end

вот так элегантно придумано блочить скомпрометированные сектора у носителей любых размеров, и здесь их по факту вероятно "плохих" секторов целых пять, а не три?
думаю, стоит разыскать больше таких реальных примеров, а то я мог сделать неверные выводы.

[Advertiser]