Half-Saint wrote on Yesterday, 09:58:

I'm not sure I fully understand the sticker on the label. What does HD stand for? Platter? Track?

HD = head = one side of a platter

You enter CYL-HD pairs.
It's normal that LLF utilities don't use the BYTE (BFI) numbers.

BTW: the optimal Interleave factor may be 2.
You can experiment with various values, and running some HDD benchmark.
You can also try Calibrate from Norton Utilities to automatically find the optimal Interleave.

That is a strange format for bad sectors: head - cylinder - byte offset.
8998 / 512 = 17.57 (and the disk has only 17 sectors per track)

BTW, I ran a Media Analysis Test from BIOS and the drive passed.

They sometimes do.
The factory bad sectors are either weak under some analogue signal level threshold, or they fix themselves in 30 years...

st31276a wrote on Yesterday, 10:47:

That is a strange format for bad sectors: head - cylinder - byte offset.
8998 / 512 = 17.57 (and the disk has only 17 sectors per track)

You're forgetting about the gaps between sectors, indexing, etc...

Half-Saint wrote on Yesterday, 09:58:

I don't particularly care about data integrity on a drive from 1989. It's not like I'll be saving important files there. Do you reckon it will be stable enough, if I just run it through SCANDISK? Getting the drive to work was the fun part. I'm not yet sure what I want to do with it as I have plenty of bigger and faster IDE drives in storage.

Would this be good enough: https://winworldpc.com/product/spinrite/ii ?

Not too sure about SCANDISK, but NDD has an extra option for surface scan - normal/daily or weekly, the second should be slower and perhaps using read-write, not just read, to test. That is still faster than SpinRite and would find any obvious problems, but not weak setors (basically places where only certain bit patterns fail to write properly).

SpinRite is way slower but it can reformat the track, individual sectors even in some cases. It will also calculate and change, if required, your sector interlave, because again it does a full low level format. But the best thing is the whole process, unless disrupted by power cut or unrecoverable read errors, does not destroy your HDD data. It will be fully preserved and weak sectors moved (well, the whole FAT clusters actually) to safer places.

For 286 interleave should be 2 or 1, 3 or higher only makes sense for XT machines. You'd need to time the reads to be sure, but running SpinRite on the target machine will take care of it for you.

You will not get interleave 1 working with a WD1003-style controller card on any type of computer. The architecture of these cards is to transfer the contents of one sector at the data rate of the medium (5MBit/s, which is 625KB/s) to the sector buffer, and while transferring the data, hardware CRC logic will verify whether the checksum is correct. Let's ignore the case in which the CRC logic reports a checksum error (it will be very slow). In case all bytes of the sector are transferred, and the trailing CRC matches the data, the controller signals the availability of 512 bytes to the host. The host then performs 256 16-bit I/O port reads to read the data from the controller RAM, while the drive keeps rotating and the next sector gets below the head before the sector transfer is complete. On a standard AT, the rate at which data can be transferred from an I/O port to memory is somewhat anove 1MB/s, so reading a sector from controller memory should be clearly faster than the time a sector requires to pass the read head.

Interleave 1 means that sector 2 is located directly after sector 1, and the controller williss sector 2 while the host transfers sector 1 data to host memory. This will get very slow. It requires 1 rotation of the disk per sector. As the disk performs 60 rotations per second and a sector is half a kilobyte, interleave 1 would result in 30KB/s.

On the other hand, interleave two puts sector 10 between sectors 1 and 2, so the sector missed while transferring sector 1 from the controller to the host is sector 10, and no one cares about that sector at this time. After sector 1 has been transferred, the read head will be close to the end of sector 10, and the next sector that approaches the head will be sector 2. This means reading a whole track of 17 sectors requires two revolutions, on to read sectors 1 to 9 and a second one to read sectors 10 to 17. A track is 8.5KB, and two revolutions happens 30 times a second, so the effective transfer rate at interleave 2 is 255KB/s.

To operate at interleave 1, you would either need to pass the sector data to the host while the sector is still being transferred to the controller, or the controller would be need to be able to receive a sector from the medium while the previous sector is still being transferred to the host. The first variant is usually not used because it prevents just in time error correction, as the wrong bits can only be identified after the complete sector has been, but at that time, the damaged bit has already been transferred to the host and can no longer be corrected by the controller.

A representative example of that time are the storage options described in the Compaq Deskpro 386/20 technical reference: A 60MB IDE drive (which is an RLL drive with a WD1003-style controller integrated in that drive, which requires interleave 2, or the choice between a 130MB half-height (1.6") or 300MB full-height (3.25") ESDI drive in combination with a ESDI controller card with 16KB buffer RAM that allows interleave 1.

As long as you can deal with the low-probability some sectors being unreadable after having the drive in storage for some years, I consider the NDD/SCANDIDK test to be perfectly acceptable. DOS already did a test like that while you ran FORMAT C: /S, so you don't need any test at all for that level of reliability.

As a hard drive rotates at 60 rotations per second, and the nominal datarate is 5MBit/s, this means a track can contain 5000kbit/60 = 83.333 kbit, which is 10 416 bytes. This is called the unformatted capacity of a track. During low level format, the track is partitioned into 17 sectors by writing 17 sector headers across the track, and the data of each sector is located shortly after the corresponding sector header. This means only 8704 bytes of user data are placed into the 10 416 bytes of unformatted data. The "bytes from index" specification just counts 8-bit intervals (each 8-bit interval is 1.6μs) since the nominal start of the track. A defect at 0 bytes from index will be before the start of the sector header of the first sector. The ration between formatted and unformatted capacity is 1.2:1 on every 17-sector MFM hard disk. This explains the Seagate model number 412 ("12" for a nominal 10MB drive), 225 ("25" for a nominal 20MB drive), 251 ("51" for a nominal 40MB drive), as these numbers are based on the "unformatted capacity".

EDIT: slightly elaborated the last paragraph and fixed rounding inaccuracies.

At the low level format level, it's odd to me that the metadata (sector headers) flagging that a track is bad is stored on the bad track.

Storing the information about bad tracks on the same track is the only solution that allows the bad track feature to be implemented without having the list of bad tracks somewhere in memory. As the marking of bad tracks is not meant to deal with circular scratched tracks after a head crash, you will be able to write most sector headers correctly. I might have seen controller firmware that errors out with the status code "bad track" if it sees *any* of the 17 headers with the "bad track" bit set, which (if correct) would explain why you only mark entire tracks as bad, and mitigate the issue that the marking might fall onto a bad spot, because it is extremely unlikely that all 17 sector headers are located at bad spots.

Sure, more elaborate solutions are possible, like for example dealing with single bad sectors by writing a "sector X is bad" header repeatedly (like 10 times ) into the space reserved for the header and the subsequent data area, which would make it likely one of the copies is readable. I never heard about a scheme like that being used in practice, though.

mkarcher wrote on Yesterday, 20:17:

As a hard drive rotates at 60 rotations per second, and the nominal datarate is 5MBit/s, this means a track can contain 5000kbit/60 = 83 kbit, which is 10.375 bytes. This is called the unformatted capacity of a track. During low level format, the track is partitioned into 17 sectors by writing 17 sector headers across the track, and the data of each sector is located shortly after the corresponding sector header. This means only 8.5 KiB of user data are placed into the 10.375 KB of unformatted data. The "bytes from index" specification just counts 8-bit intervals (each 8-bit interval is 1.6μs) since the nominal start of the track. A defect at 0 bytes from index will be before the start of the sector header of the first sector.

Excellent explanation, thank you.