ST2000LM007 - Weird Read Issue

[lcoughey]

Patient Drive - ST2000LM007, 1R8174-568, WDZ..., SBK2, 4 heads

The heads were found to be knocked onto the platter surfaces. After removing and inspecting the heads, put back into parking position and detected without issue on PC3000.

When mirroring, all 4 heads read without any issues at the start, but head 3 hits a spot where it reads very slowly and still returns green "healthy" blocks. However, it would appear that as soon as head 3 crosses a certain point in the LBA, it starts goes from reading good data to reading repeated garbage.

NOTE: The sectors all read green in UDMA mode. I changed the corrupt sector map to orange to help make it easier to find the corrupt sectors.

Good sector in MFT


Corrupt sector in MFT


I have never seen this before in a Rosewood drive and only quickly discovered the issue because another technician informed me of the same issue they encountered last week. The other lab was able to resolve the issue with a head change.

I'm hoping to find a solution and not need to change the heads. I just figured I'd throw this out there, just in case someone else has encountered this issue and has a solution to share, other than a head swap. Or, if you just encountered the issue, know that you are not alone.

I will follow up if I find out anything helpful.

What to enter in your grep search:

Code: Select all

mo.L.D -> ^\x6D\x6F\x93\x4C\xD2\x44
sEDU -> ^\x73\x45\x44\x55

Here are the ACE Lab instructions to create a GREP map for these errors and to use the newer GREP functions:

[lcoughey]

Thus far, the best I've been able to confirm is that the only known solution is to change the heads.

[lcoughey]

Changed heads, still getting the odd random sectors showing as green healthy blocks, but still reading garbage. So, I'll have to do a grep search for the corrupt sector header and change the map of those sectors to damaged after I complete imaging by bitmap. Most sectors are reading as they should.

[lcoughey]

We were able to complete mirroring by bitmap with only 5 bad sectors, none of which were in any client data files. So, we got a 100% clean recovery here.

[lcoughey]

I have another drive with similar issues. This time with "sEDU"
Patient Drive - ST2000LM007, 1R8174-568, WDZ..., SBK2, 4 heads
Perhaps it is only with this model that this issue occasionally happens. Not enough cases to make that call.
---

ST2000LM007-Corrupt-Sectors.jpg (84.21 KiB) Viewed 12466 times

---
Update: changed the heads and the garbage sectors are slowly reading good data now. But, as before, still getting random sectors read with the corrupt pattern

[lcoughey]

I have a completely different model with similar symptoms. This is with donor heads and the garbage isn't in every sector read with the one head, head 0, in this case. But, what is interesting is that every case I see this happening in, the one thing that has been consistent is that it always seems to land in the MFT or HFS+ catalog.

ST4000LM024
2AN17V-566
WFF...
---

ST4000LM024-2AN17V-WFF-garbage-sector.png (26.33 KiB) Viewed 10083 times

[Joep]

Patient Drive - ST2000LM007, 1R8174-568, WDZ..., SBK2, 4 heads

The heads were found to be knocked onto the platter surfaces. After removing and inspecting the heads, put back into parking position and detected without issue on PC3000.

When mirroring, all 4 heads read without any issues at the start, but head 3 hits a spot where it reads very slowly and still returns green "healthy" blocks. However, it would appear that as soon as head 3 crosses a certain point in the LBA, it starts goes from reading good data to reading repeated garbage.

NOTE: The sectors all read green in UDMA mode. I changed the corrupt sector map to orange to help make it easier to find the corrupt sectors.

Good sector in MFT


Corrupt sector in MFT


I have never seen this before in a Rosewood drive and only quickly discovered the issue because another technician informed me of the same issue they encountered last week. The other lab was able to resolve the issue with a head change.

I'm hoping to find a solution and not need to change the heads. I just figured I'd throw this out there, just in case someone else has encountered this issue and has a solution to share, other than a head swap. Or, if you just encountered the issue, know that you are not alone.

I will follow up if I find out anything helpful.

But, am I seeing correctly that's in the second sector of the same file record, right?

I see sector no 133040228 in screenshot 1 and sector no 133040229 in 2nd. As one file record is usually 1024 bytes, these are two halfs of one file record. However, looking at sector 133040228 I see the first line of the next sector with only zeros (byte values 02 00 are last two bytes of first sector). So that's the first 16 bytes of 133040229, no? In 2nd screenshot, first 16 bytes of 133040229 are no longer zeros.

[lcoughey]

I was just showing a good vs damaged sector. All sectors for the one head after the good sector were bad in that case until I changed to another set of heads.

[Joep]

Ok. And sectorsize > 512 then?

[lcoughey]

Ok. And sectorsize > 512 then?

That is correct.