SpinRite

[fzabkar]

I notice that SpinRite fails to read 7 out of 8 logical sectors from a particular physical sector, but successfully reads the 8th one. I have also seen this behaviour in professional tools. How can this be possible? If one can read part of a physical sector, then one should be able to read the entire physical sector, or am I missing something?

Here is the first example (there are several others). Notice that sector 40,335,935 is missing.

Code: Select all

|--------------------------------------------------------------------------|
| Sector 40,335,928 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,929 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,930 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,931 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,932 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,933 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,934 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,948,232 (4.1921%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|

Could it be that the ECC bytes for each sector are organised as 8 groups, with each group associated with one logical sector?

(ISTR that I was involved in a similar discussion, but I forget where it was.)

[fzabkar]

Isn't this how it should work, assuming that the result of reading a physical sector is all-or-nothing?

read 40,335,928 -- fail after exhausting retries
read 40,335,929 -- fail after exhausting retries
read 40,335,930 -- fail after exhausting retries
read 40,335,931 -- fail after exhausting retries
read 40,335,932 -- fail after exhausting retries
read 40,335,933 -- fail after exhausting retries
read 40,335,934 -- fail after exhausting retries
read 40,335,935 -- success
reread 40,335,928 -- it should now be in the HDD's SDRAM read cache
reread 40,335,929 -- it should now be in the HDD's SDRAM read cache
reread 40,335,930 -- it should now be in the HDD's SDRAM read cache
reread 40,335,931 -- it should now be in the HDD's SDRAM read cache
reread 40,335,932 -- it should now be in the HDD's SDRAM read cache
reread 40,335,933 -- it should now be in the HDD's SDRAM read cache
reread 40,335,934 -- it should now be in the HDD's SDRAM read cache

[CrazyTeeka]

Sector 40,335,935 looks like it was read successfully so doesn't appear in the logs.
This pattern of failing to read 7 out of 8 logical sectors sounds interesting.

> Could it be that the ECC bytes for each sector are organised as 8 groups, with each group associated with one logical sector?
If the evidence points to that it must be the case.

[Joep]

I notice that SpinRite fails to read 7 out of 8 logical sectors from a particular physical sector, but successfully reads the 8th one. I have also seen this behaviour in professional tools. How can this be possible? If one can read part of a physical sector, then one should be able to read the entire physical sector, or am I missing something?

Here is the first example (there are several others). Notice that sector 40,335,935 is missing.

Code: Select all

|--------------------------------------------------------------------------|
| Sector 40,335,928 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,929 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,930 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,931 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,932 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,933 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,335,934 (4.1295%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|
| Sector 40,948,232 (4.1921%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |
|--------------------------------------------------------------------------|

Could it be that the ECC bytes for each sector are organised as 8 groups, with each group associated with one logical sector?

(ISTR that I was involved in a similar discussion, but I forget where it was.)

HAH! I noticed this too, https://forums.grc.com/threads/st950042 ... post-10062

[Joep]

Sector 40,335,935 looks like it was read successfully so doesn't appear in the logs.
This pattern of failing to read 7 out of 8 logical sectors sounds interesting.

> Could it be that the ECC bytes for each sector are organised as 8 groups, with each group associated with one logical sector?
If the evidence points to that it must be the case.

That makes no sense, the 4K sector is smallest unit the drive can address, read from or write to. AFAIK ECC is 'computed' over 4096 bytes, the whole sector.

[CrazyTeeka]

That makes no sense, the 4K sector is smallest unit the drive can address, read from or write to. AFAIK ECC is 'computed' over 4096 bytes, the whole sector.

Are we sure this drive uses 4k sectors? Because I've not checked if it does.

[fzabkar]

Sector 40,335,935 looks like it was read successfully so doesn't appear in the logs.
This pattern of failing to read 7 out of 8 logical sectors sounds interesting.

> Could it be that the ECC bytes for each sector are organised as 8 groups, with each group associated with one logical sector?
If the evidence points to that it must be the case.

That makes no sense, the 4K sector is smallest unit the drive can address, read from or write to. AFAIK ECC is 'computed' over 4096 bytes, the whole sector.

That's the way that Wikipedia explains it, and that's what I've always thought to be the case.

https://en.wikipedia.org/wiki/Advanced_Format#Overview

The following structure could explain why these tools recover partial physical sectors. It would be far less efficient, though.

gap + sync + address mark + 512 bytes + ECC + 512 bytes + ECC + 512 bytes + ECC ... + 512 bytes + ECC

What would be an alternative explanation? AFAICT, in all the "partial" cases the last sector is recovered but not 0 - 6. Is it merely coincidence?

[CrazyTeeka]

Drive specifications...

[Joep]

Sector 40,335,935 looks like it was read successfully so doesn't appear in the logs.
This pattern of failing to read 7 out of 8 logical sectors sounds interesting.

> Could it be that the ECC bytes for each sector are organised as 8 groups, with each group associated with one logical sector?
If the evidence points to that it must be the case.

That makes no sense, the 4K sector is smallest unit the drive can address, read from or write to. AFAIK ECC is 'computed' over 4096 bytes, the whole sector.

That's the way that Wikipedia explains it, and that's what I've always thought to be the case.

https://en.wikipedia.org/wiki/Advanced_Format#Overview

The following structure could explain why these tools recover partial physical sectors. It would be far less efficient, though.

gap + sync + address mark + 512 bytes + ECC + 512 bytes + ECC + 512 bytes + ECC ... + 512 bytes + ECC

What would be an alternative explanation? AFAICT, in all the "partial" cases the last sector is recovered but not 0 - 6. Is it merely coincidence?

Yes, I see your point, but it's not just WikePedia explaining it like that, also Seagate and Toshiba for example (https://www.officeproductnews.net/sites ... aper_0.pdf).

512b sectors are 'emulated', right? It's basically a firmware thing that reads 4096 bytes, ECC checks/corrects that and delivers the 512 bytes the host asked for. Even if the drive did ECC every 512 byte chunk then I still don't see how accidentally first 7 chunks all go bankrupt and the 8th does not, in multiple 4K sectors. Makes no sense to me ..

Okay, say 4096 sector with 100 ECC bytes. If I am not mistaken, default ECC bytes for .5K sector is 50. If ECC is done per .5K bytes there's hardly room for any ECC bytes, 100 / 8. No I can not see how .5K sector size emulation is anything other than purely a controller/firmware thing.

Let's consider:

We're looking at SpinRite output, right? Look at:

"| Sector 40,948,235 (4.1921%) was found but, despite SpinRite's every |
| effort, none of its data could ever be recovered. |"

It makes very little sense to me and I wonder what he's even doing there. It annoys the heck out of me that everything he does is so vague.

When you read a sector the outcome is quite binary: either a sector gives you data, all data, or no data at all. Unless SG tries long reads, because we know for a fact he still hasn't abandoned this idea. Perhaps something weird comes out of that. But then still RapidSpar saw the same 81 (512 byte I assume) sectors as problematic. Does RapidSpar create some detailed logfile somewhere? With actual return codes from that drive?

Still find it weird that SMART pending's still at 7 and reallocated at 0.

[CrazyTeeka]

> It annoys the heck out of me that everything he does is so vague.
We're not going to get much out of tight lipped Steve, we just do our own investigation.

I'm going to source some more drives with bad sectors to investigate this some more.

What I did and what I know so far...

1. Put drive on RapidSpar first - It found 81 unrecoverable sectors.
2. Put drive on SpinRite next - Level 2 with default dynastat time of 5 minutes, it also found 81 unrecoverable sectors.
3. Put drive on RapidSpar again - It found 81 unrecoverable sectors again.
4. Put drive on SpinRite again - Level 2 with dynastat 0 this time, it didn't even slow down, the previous bad sectors just vanished, pretty sure they were swapped out for good sectors, but SMART isn't reporting any changes on this.
5. Put drive on RapidSpar again - It found 0 unrecoverable sectors this time.

I too find it weird that SMART pending's still at 7 and reallocated at 0. The drive has been read from 0% to 100% many times since and that's not changing, I wonder if SMART has been taken offline, or maybe that's just how SMART works on this drive.

What if there is a firmware problem in the service area? Probably isn't but it's something I thought about.

I'll keep the RapidSpar log files next time, but first run identified something of interest anyway.