Early IBM disks and bad blocks

[romanon]

Hello, I have a problem with MFM disks, especially the ones offered by IBM for their early PCs. Specifically, I have the Seagate ST-412 and Miniscribe 2012 models installed in IBM PC 5160 and 5161. I only power them on on special occasions, and I always test them using the Spinrite (on level 4) program beforehand. Unfortunately, every year, I find more bad blocks using this method. Is there a way to reverse this process or at least slow it down? The disks are otherwise in good condition, and the motor is almost silent.

Thanks

 

[krebizfan]

Nothing will reverse it. Some of the bad blocks might be incorrectly identified and restored to use but I would not do that. Intermittent failures tend to recur risking either data loss or, in the very best case, a slow system as numerous retries occur when reading that block. Parking the drives at the end of a session is the only action that could slow the damage but running the drives carries the risk of a head crash or moving contaminants around the disk.

Getting about 40 years of use out of hard drives is impressive.

 

[Timo W.]

Make sure the bad blocks listed on the label are marked as bad, otherwise you may see exactly that behaviour (they are written down on the label for a reason).

Another thing many people are not aware these days: these drives must warm up to perform correctly. Do not check for bad blocks on a drive you just powered up. Let it run for 20 minutes first.

 

[romanon]

I don't have any stickers indicating bad blocks on the disks. What's the reason for testing the disks only after they've warmed up? I've never heard about this before.

 

[modem7]

I don't think it is a requirement of MFM/RLL drives for PC and compatibles; more of a recommendation.

For example, in the Seagate document 'ST-506 MICROWINCHESTER SERVICE MANUAL MAY 1, 1982' is the following:

"Thermal isolation of the stepper and spindle motor assemblies from the disc enclosure yields a very low temperature rise within the enclosure, providing significantly greater off-track margin
and the ability to immediately perform read and write operations after power up with no thermal stabilization delay."

So, when the drive is cold, the heads-to-platter relationship is not normally where it is (normal: when the drive is at normal operating temperature), but it is still within the 'capture range' of the drive.

If I am low-level formatting an MFM/RLL drive, ideally, I want to do that when the heads-to-platter relationship is where it is in the vast majority of its powered-up (operating) time. So I always low-level format after a warm-up period.

Similarly, if I am testing an MFM/RLL drive, ideally, I want to do that when the heads-to-platter relationship is where it is in the vast majority of its powered-up time.

 

[modem7]

Every few months or so, I would hear the hard drive in my main IBM 5170 retrying a read. I would run Norton Disk Doctor, and that would find defective sectors and mark the associated clusters as bad. This had been going on for say, a couple of years (when I last low-level formatted the drive). It got to the point that I felt, for no particular reason, that I should low-level format the drive again.

No tracks on the drive's bad track sticker. I used SpeedStor software to perform the low-level format. During that operation SpeedStor declared about 5 tracks to be defective.

But then I ran SpeedStor's 'media analysis' functionality, and over hours, that declared many more tracks to be defective. The 'media analysis' functionality tests the drive extensively using varying data patterns. Pattern testing is something that Chuck(G) recently brought up.

Perhaps when I previously low-level formatted the drive, I did not do the 'media analysis' bit.

 

[Chuck(G)]

Always wondered why none of the ST506-interface firmware had provisions for re-mapping bad blocks to spare area. Of course, modern disks do that, so one does not expect to see a bad block ever. But the re-mapping scheme is much older than even the ST506 drive.

 

[djg]

Always wondered why none of the ST506-interface firmware had provisions for re-mapping bad blocks to spare area.

If you are referring to the firmware in the drive the drive knows nothing about the data. The MFM data signal to the controller is just the analog signal from the head cleaned up and sent out digital. A number of MFM controllers did do bad block remapping. They had access to the decoded sector data. The one IBM picked for the XT didn't do remapping.

 

[Chuck(G)]

I'm talking about the controller firmware--you know, the stuff in the controller ROMs. I"m well aware of how ST506 interface drives work and have posted on the subject multiple times. Basically big floppy drives.

 

[djg]

I'm talking about the controller firmware--you know, the stuff in the controller ROMs

A number of MFM controllers did do bad block remapping

I did answer that also. Since your wording was ambiguous on what firmware you were referring to I also answered more fully. Not everybody is familiar with how the interface works.

 

[Chuck(G)]

Back in the days of databases that spanned many 844-2 (100 MB) pack drives, we had something we called "write divert". The idea was that loading all those drives from 7 track tape could take much of a day, so if you were testing code, you didn't want to mess it up. "Write divert" remapped disk writes to a spare set of packs, so the original stuff was left untouched.
Was there ever a facility for this in the ST506/412 world? This was in the early 70s.

 

[djg]

I've never seen that for ST506 type controllers.

 

[romanon]

I have one more thing on my mind. Is it appropriate to use low versions of DOS on these disks? For authenticity, I use versions of DOS lower than 3.0 on my IBM 5160 and 5161. However, I know that early versions of DOS had a bug that caused errors in writing (the case of CMI disks in the first 5170s)."

 

[djg]

However, I know that early versions of DOS had a bug that caused errors in writing (the case of CMI disks in the first 5170s)."

Hadn't heard of that so went digging. What I found seems to say they made DOS 3.1 able to handle bad sectors in the beginning of the disk due to deal with the bad CMI drives. Do you know of something else?
https://www.minuszerodegrees.net/51...170 - 6426 problems - Computerworld JAN85.jpg

 

[romanon]

Hadn't heard of that so went digging. What I found seems to say they made DOS 3.1 able to handle bad sectors in the beginning of the disk due to deal with the bad CMI drives. Do you know of something else?
https://www.minuszerodegrees.net/5170/cmi_6426_problems/IBM 5170 - 6426 problems - Computerworld JAN85.jpg

It might be the case. I'm not sure if it was related only to CMI disks or if it was a general measure. So, in this case, the version of DOS doesn't matter?

 

[krebizfan]

I don't know of any hard drive killing bug in any version of DOS 2. I think the trade magazines would have made considerable noise if it happened. I wouldn't go out of my way to run a prerelease version of PC-DOS 2 either just to be on the safe side.

 

[offensive_Jerk]

I have one more thing on my mind. Is it appropriate to use low versions of DOS on these disks? For authenticity, I use versions of DOS lower than 3.0 on my IBM 5160 and 5161. However, I know that early versions of DOS had a bug that caused errors in writing (the case of CMI disks in the first 5170s)."

I just found this snippet looking for a Tall Tree Systems JRAM-2 manual:

DOS 2.00 and 2.10 have a bug in them that makes it dangerous to change volume labels. To avoid destroying arbitrary
files (due to the bug) we have modified the LABEL.COM program
to automatically abort if there is a pre-existing label on a volum

 

[modem7]

DOS 2.00 and 2.10 have a bug in them ...

There will be other issues as well. For example, see "Bad Track 0" at [here].