Recovery Force® Data Recovery Forum

I posted about this on the Ace forums a while back and thought I'd post a summary here after encountering a second drive with the same symptoms. These drives have 10 heads and when mirroring in DE, the 10th head is not reading any sectors. I was unable to find a solution for the first drive with the issue in 2016, but figured it out with a drive I received earlier this month

Default Head Map in NVRAM
Drive 1 - 07 06 05 04 03 02 01 00 D8 A2
Drive 2 - 07 06 05 04 03 02 01 00 59 F1

When I compared a working drive's headmap to Drive 2's headmap, even though the last two heads don't precede with a 0, the ending number does appear to need to match with the physical head number. So, D8 for the first drive is actually head 08 or the 9th head, suggesting that A2 should be the 10th physical head 09. And, with the second drive, 59 is the 10th head 09, which means that F1 should actually be 08, the 9th physical head.

Sure enough, when I changed Drive 2's head map to the following, the last head started to read.

Drive 2 - 07 06 05 04 03 02 01 00 59 08

So, if the theory holds true, the first drive's dead head would have read had I changed the headmap to the following:

Drive 1 - 07 06 05 04 03 02 01 00 D8 09

I don't have any explanation as to why Hitachi did things this way, it does seem clear that something happened to the drive which caused the headmap in the NVRAM to get damaged and drop the last head.

Drive Headmaps (for reference and proof of my theory)

07 06 05 04 03 02 01 00 D9 A8 - Healthy
07 06 05 04 03 02 01 00 B1 26 - Healthy
07 06 05 04 03 02 01 00 D8 A2 - Logical head 9 not reading any sectors
07 06 05 04 03 02 01 00 59 F1 - Logical head 9 not reading any sectors

As we can see with one of the healthy drives, my theory about the head maps is incorrect.

Great info Luke.

After further exploration, here is what I've found in the NVRAM for the headmap.

Sector 0x06A holds the number of heads in hex:
0A = 10 heads
09 = 9 heads
08 = 8 heads
...and so on

At sector 0x252, the headmap starts, preceded by 0xB7 0xB0. But, for some reason, the utility in DE is off by 2 bytes and starts reading at 0x254

1TB 10 Head Example:
NVRAM file in Hex Editor @ 0x24C: 09 08 07 06 05 04 03 02 01 00 followed by 77 C8
NVRAM via utility reads 07 06 05 04 03 02 01 00 77 C8, clearly missing the target

750GB 8 Head Example:
NVRAM file in Hex Editor @ 0x24C: 07 06 05 04 03 02 01 00 0F 0F

I am only looking at the 750GB drive via the backed up resources and don't have a working one here, but I believe the error only lies with the 10 head version of this drive. If someone happens to have a KLA series 750GB drive that they can connect in and confirm, it would be appreciated.

After communicating with ACE TS about this (yes, I have another one of these drives here), they have pointed me to the IBMOverride.ini file in the !Profiles\HITACHI-IBM folder where we are to make note of the correct headmap location. Oddly enough, the file with the last modification date of 2014 (never by me) already has a comment about the different location:
I'm waiting for ACE TS to give me to the correct syntax to correctly add the modification. I've already confirmed that NVR_HEADMAP_Offs = 024C does not work, unless it is necessary to completely close PC3000, instead of exiting and reloading the utility.

ACE TS suggests that the new line should be
NVR_Head_Map_Offs = 024C

But it isn't working for me.

Would it be feasible to search for NVR related text strings in Ace's software, assuming the software isn't locked down?

The developers connected in and confirmed it doesn't work. For now, hex editor is needed for manual head map adjustments.