The wrap-up:
So I got the data off the drive. :)
One issue is it turns out the drive is a bit flaky. I'm not sure how
much of the issue is heat, and how much is tilt. I had done most of my
fiddling with the drive perched in places that weren't quite flat, and I
think these old drives must have been more sensitive to that,
considering that I discovered this morning that the data sheet on TH99
says not to tilt it more than 5 degrees (!) from horizontal.
I tried older hardware, and DOS-type stuff, but didn't get anywhere,
although there were intermittent moments when things worked. See above.
What finally worked was the same P3 setup and a bit of kernel hacking,
plus getting past the flakiness. However, I think I found an obscure
kernel bug that probably wouldn't affect anyone except people trying to
do what I did. In wd_get_params() in dev/ata/wd.c, if the kernel gets
an error when it tries to get ATA info from a drive (and this one is
pre-ATA), it uses 1024/8/17 and single-sector transfers with no ATA
capabilities. This is the comment:
/*
* We `know' there's a drive here; just assume it's old.
* This geometry is only used to read the MBR and print a
* (false) attach message.
*/
However, that doesn't seem to be the case. The P3's BIOS doesn't even
provide info about the MFM drive, but on a P1, with an old OBSD boot
floppy, 'machine diskinfo' at the boot> prompt gave me 614(?!)/4/17,
which is more or less correct - and then the dmesg used 1024/8/17. And
I know that it wasn't just faked for the dmesg, because of the numbers
in the error messages I got, eg 'blah blah fsbn xxx (bn x: cn y, tn z,
sn q)' - to get those c/t/s numbers for that block number meant the
kernel was using 1024/8/17 to access the drive. I haven't replicated
this with a more recent kernel, but I suspect this code hasn't been
touched in a while, considering that 4.6-release does the same thing.
Presumably, if the kernel is actually going to use LBA mode, or the
ATA-info error is transient or whatever, this hack won't cause any
problems. But has anyone else tried to use a CHS-mode-only drive with
geometry other than 1024/8/17 with success? Is there a provision
somewhere else to get the correct numbers?
In any case, I changed those numbers to the correct ones for the drive
and recompiled the kernel. Initially it didn't work (flakiness), but
when I tried again this morning with the drive level and cold, I was
able to get almost everything off the drive. The rest is probably
attributable to bad sectors, considering the drive is around 20 years old.
Here are the results you've been waiting for :)
---
dmesg:
wdc0 at isa0 port 0x1f0/8 irq 14
wd1 at wdc0 channel 0 drive 0: <ST506>
wd1: 1-sector PIO, CHS, 68MB, 1024 cyl, 8 head, 17 sec, 139264 sectors
wd1(wdc0:0:0): using BIOS timings
---
fdisk:
Disk: wd1 geometry: 615/4/17 [41820 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: 04 0 1 1 - 613 3 17 [ 17: 41735 ] DOS
FAT-16
---
disklabel:
# /dev/rwd1c:
type: ST506
disk: ST506/MFM/RLL
label: ST506
flags:
bytes/sector: 512
sectors/track: 17
tracks/cylinder: 4
sectors/cylinder: 68
cylinders: 615
total sectors: 41820
rpm: 3600
interleave: 1
boundstart: 0
boundend: 41820
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
c: 41820 0 unused
i: 41735 17 MSDOS
---
df:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/wd0a 5038086 3078892 1707290 64% /
/dev/wd0d 148271564 101606904 39251082 72% /data
/dev/wd1i 20810 8924 11886 43% /mnt
