[SOLVED] Toshiba Disk Shift values - are they accurate and do they matter?

[PiersJH]

This is posted in reference to an older thread - link here - but tldr; I have two N300 8TB drives and the Disk Shift value seems to go from hundreds of thousands to tens of millions. Reading about these SMART value makes me concerned as none of my other drives have them, but the consensus seems to be that those specific Toshiba values are not too much of a concern. Is that accurate?

Detail
I've finally registered here to ask about Disk Shift values as I've never noticed them before on other drive brands (WD, Seagate, HGST) and have just purchased two Toshiba N300 8TB drives. They both have varying (in the tens of millions to hundreds of millions) SMART Disk Shift values. @madmatt30 posted on the linked thread that Toshiba doesn't measure the value correctly, but I couldn't find a source on this - only conflicting opinions from various websites. Does anyone know more about this value in relation to Toshiba drives? Is a high number indication of failure, or is it merely Toshiba drives not reporting the value correctly so it can be ignored?

Drive Tests Completed

1. Short self test (2m)
2. Extended self-test (700m)
3. HD Sentinel WRITE+READ (writes data to every sector - fills the drive, then reads data back and confirms CRC values, as far as I'm aware) (20 hours)

Both drives passed. The Disk Shift values seems (on one drive) decrease with reboots, then increase once booted).

Other people's experiences w/ Toshiba drives and Disk Shift
Reddit (1,2,3)

Here are some screenshots of the Disk Shift values and SMART values (sorry, I couldn't work out how to insert thumbnails instead of the full size image):
Drive #1

Disk #2

Any advice or assistance is greatly appreciated. Thank you.

 

[fzabkar]

Those raw numbers are best interpreted in hexadecimal.

https://www.google.com/search?q=134217731+in+hexadecimal

134 217 731 = 0x08000003
 84 672 513 = 0x050C0001

That said, I can see that the raw value consists of two or more hexadecimal numbers, but I can't work out what they mean.

For example, the first raw value appears to be two hex numbers, 0x0800 and 0x0003. The second appears to be 0x050C and 0x0001.

If you use CrystalDiskInfo, its default output format is hexadecimal.

For those 3 Reddit threads ...

134 479 873 = 0x0804 0001
 51 642 387 = 0x0314 0013
201 326 602 = 0x0C00 000A
    524 297 = 0x0008 0009
 52 035 625 = 0x031A 0029

 

[PiersJH]

Those raw numbers are best interpreted in hexadecimal.

https://www.google.com/search?q=134217731+in+hexadecimal

134 217 731 = 0x08000003
84 672 513 = 0x050C0001

That said, I can see that the raw value consists of two or more hexadecimal numbers, but I can't work out what they mean.

For example, the first raw value appears to be two hex numbers, 0x0800 and 0x0003. The second appears to be 0x050C and 0x0001.

If you use CrystalDiskInfo, its default output format is hexadecimal.

For those 3 Reddit threads ...

134 479 873 = 0x0804 0001
51 642 387 = 0x0314 0013
201 326 602 = 0x0C00 000A
    524 297 = 0x0008 0009
52 035 625 = 0x031A 0029

Sorry, I changed the reporting to decimal as it made more sense to me. Here are the raw values.

ID Cur Wor Thr RawValues(6) Attribute Name
01 100 100 _50 000000000000 Read Error Rate
02 100 100 _50 000000000000 Throughput Performance
03 100 100 __1 000000002BA6 Spin-Up Time
04 100 100 __0 000000000005 Start/Stop Count
05 100 100 _50 000000000000 Reallocated Sectors Count
07 100 100 _50 000000000000 Seek Error Rate
08 100 100 _50 000000000000 Seek Time Performance
09 100 100 __0 000000000071 Power-On Hours
0A 100 100 _30 000000000000 Spin Retry Count
0C 100 100 __0 000000000005 Power Cycle Count
BF 100 100 __0 000000000000 G-Sense Error Rate
C0 100 100 __0 000000000001 Power-off Retract Count
C1 100 100 __0 000000000014 Load/Unload Cycle Count
C2 100 100 __0 002B00130029 Temperature
C4 100 100 __0 000000000000 Reallocation Event Count
C5 100 100 __0 000000000000 Current Pending Sector Count
C6 100 100 __0 000000000000 Uncorrectable Sector Count
C7 200 200 __0 000000000000 UltraDMA CRC Error Count
DC 100 100 __0 000007040008 Disk Shift
DE 100 100 __0 000000000042 Loaded Hours
DF 100 100 __0 000000000000 Load/Unload Retry Count
E0 100 100 __0 000000000000 Load Friction
E2 100 100 __0 000000000200 Load 'In'-time
F0 100 100 __1 000000000000 Head Flying Hours

Image in case above is unclear:

ID Cur Wor Thr RawValues(6) Attribute Name
01 100 100 _50 000000000000 Read Error Rate
02 100 100 _50 000000000000 Throughput Performance
03 100 100 __1 000000002C67 Spin-Up Time
04 100 100 __0 000000000005 Start/Stop Count
05 100 100 _50 000000000000 Reallocated Sectors Count
07 100 100 _50 000000000000 Seek Error Rate
08 100 100 _50 000000000000 Seek Time Performance
09 100 100 __0 000000000071 Power-On Hours
0A 100 100 _30 000000000000 Spin Retry Count
0C 100 100 __0 000000000005 Power Cycle Count
BF 100 100 __0 000000000000 G-Sense Error Rate
C0 100 100 __0 000000000001 Power-off Retract Count
C1 100 100 __0 00000000001A Load/Unload Cycle Count
C2 100 100 __0 002D00170027 Temperature
C4 100 100 __0 000000000000 Reallocation Event Count
C5 100 100 __0 000000000000 Current Pending Sector Count
C6 100 100 __0 000000000000 Uncorrectable Sector Count
C7 200 200 __0 000000000000 UltraDMA CRC Error Count
DC 100 100 __0 000002020001 Disk Shift
DE 100 100 __0 00000000003C Loaded Hours
DF 100 100 __0 000000000000 Load/Unload Retry Count
E0 100 100 __0 000000000000 Load Friction
E2 100 100 __0 0000000001FA Load 'In'-time
F0 100 100 __1 000000000000 Head Flying Hours

Image in case above is unclear:

 

[fzabkar]

I'm now back to thinking that the raw value is in 3 parts:

0x02020001  -> 0x02 / 0x02 / 0x0001
0x07040008  -> 0x07 / 0x04 / 0x0008

However, that still doesn't help me to understand what the numbers actually mean. In any case it seems that these numbers are probably normal.

 

[PiersJH]

I'm now back to thinking that the raw value is in 3 parts:

0x02020001  -> 0x02 / 0x02 / 0x0001
0x07040008  -> 0x07 / 0x04 / 0x0008

However, that still doesn't help me to understand what the numbers actually mean. In any case it seems that these numbers are probably normal.

And that's the part I'm having a tough time with understanding. Acronis has a good definition of Disk Shift; "[d]isk Shift S.M.A.R.T. parameter indicates that a distance of the disk has shifted relative to the spindle, which could be caused by a mechanical shock or high temperature", but this doesn't explain why other manufacturers don't use the attribute and what it means in real terms.

As you saw from the reddit posts I linked in the initial post, three people with (I believe) 10 drives running 24/7 with Disk Shift values have not seen any serious SMART errors and report the drives as being fine. And then there's the quote from @madmatt30 in a prior thread, where he stated: "Disk shift doesn't report properly on Toshiba drives so you can ignore that."

Below are two more images, but this time in raw (hex) and with the graph attached. This is after a reboot and you can see the value has changed compared to the initial post.

 

[fzabkar]

Those graphs are pointless. They treat the raw value as a single large number rather than 3 smaller components. By way of comparison, look at the temperature attribute. The raw value consists of three 16-bit components which report the maximum, minimum and current temperatures for the current power cycle.

I suspect that the actual disk shift is reported in the lower 16 bits. The two upper 8-bit components could be some kind of coefficients, perhaps related to repeatable runout (RRO). These coefficients are possibly sine and cosine values, as explained in the following patent:

https://patents.google.com/patent/US20050128635

 

[PiersJH]

Those graphs are pointless. They treat the raw value as a single large number rather than 3 smaller components. By way of comparison, look at the temperature attribute. The raw value consists of three 16-bit components which report the maximum, minimum and current temperatures for the current power cycle.

I suspect that the actual disk shift is reported in the lower 16 bits. The two upper 8-bit components could be some kind of coefficients, perhaps related to repeatable runout (RRO). These coefficients are possibly sine and cosine values, as explained in the following patent:

https://patents.google.com/patent/US20050128635

If so, what's happening when only two values are shown?

 

[fzabkar]

I don't know what the numbers mean, but if we take the lower 16-bits to be the actual disk shift, then your data are 3, 1, 8, 1, 2, 0. Those would be the points in my graph.

It seems to me that this is not a significant fluctuation. I think all you can do is compare this attribute with other working Toshiba drives. If this were my drive, I would not be concerned.

Edit:

Here is an interesting thread:

View: https://www.reddit.com/r/DataHoarder/comments/gc3swf/return_toshiba_drive_with_high_disk_shift_smart/g28dd0p/?context=3


The user has a Toshiba MG07ACA14TE HDD with a disk shift of 134479786.

134479786 = 0x803FFAA -> 0x08 / 0x03 / 0xFFAA

The last number, 0xFFAA, is actually a negative 16-bit number, with a decimal value of -86. So this would tend to support my theory.

 

[fzabkar]

Here is a thread about a failing Toshiba HDD:

https://www.sevenforums.com/hardwar...rd-drive-failing-post2230604.html#post2230604

Model Number: TOSHIBA MK6465GSXN

SMART ATTRIBUTES:
ID Description Status Value Worst Threshold Raw Value TEC
---------------------------------------------------------------------------------------------------------------------------------------------
1 Raw Read Error Rate OK 100 100 50 0 N.A.
2 Throughput Performance OK 100 100 50 0 N.A.
3 Spin Up Time OK 100 100 1 2122 N.A.
4 Start/Stop Count OK 100 100 0 4014 N.A.
5 Reallocated Sector Count FAIL 8 8 50 2031 N.A.
7 Seek Error Rate OK 100 100 50 0 N.A.
8 Seek Time Performance OK 100 100 50 0 N.A.
9 Power On Time OK 89 89 0 4678 N.A.
10 Spin Retry Count OK 180 100 30 0 N.A.
12 Power Cycle Count OK 100 100 0 3998 N.A.
191 G-sense Error Rate OK 100 100 0 63 N.A.
192 Power off Retract Count OK 100 100 0 35 N.A.
193 Load Cycle Count OK 95 95 0 54450 N.A.
194 Temperature OK 100 100 0 38 C N.A.
196 Reallocation Event Count OK 100 100 0 245 N.A.
197 Current Pending Sector Count OK 100 100 0 0 N.A.
198 Uncorrectable Sector Count OK 100 100 0 0 N.A.
199 UltraDMA CRC Error Count OK 200 200 0 0 N.A.
220 Disk shift OK 100 100 0 8287 N.A.

I don't know if this older model uses the same reporting format, but ...

8287 = 0x205F

Either that's a very big shift, or the number is in two parts, 0x20 and 0x5F.

 

[USAFRet]

This, from a 7 month old Toshiba Enterprise, 16TB.

As reported by my QNAP

From CrystalDiskInfo

 

[fzabkar]

Ouch! It appears that each point in the normalised Reallocated Sectors Count corresponds to 100 sectors, in which case Toshiba wants your drive to develop 9000 bad sectors before it triggers a SMART failure. :-(

https://ipv4.google.com/search?q=0x493+/+(100+-+89)

0x493 / (100 - 89) = 106.5
0x493 / (100 - 88) = 97.6

 

[USAFRet]

Ouch! It appears that each point in the normalised Reallocated Sectors Count corresponds to 100 sectors, in which case Toshiba wants your drive to develop 9000 bad sectors before it triggers a SMART failure. :-(

https://ipv4.google.com/search?q=0x493+/+(100+-+89)

0x493 / (100 - 89) = 106.5
0x493 / (100 - 88) = 97.6

The only real 'ouch' is the wait for the replacement to arrive.

 

[fzabkar]

I would expect that your drive could become "laggy" when hitting those Current Pending and Uncorrectable sectors. An Uncorrectable Sector Count of 0x2F67 corresponds to 12135 physical sectors, which is 97080 logical sectors. At the moment the drive has reallocated 9368 logical sectors.

BTW, the drive is still reporting a 100% normalised value for the Current Pending Sector Count and Reallocation Event Count, even though the raw values are 2048 and 1170, respectively. That's misleading, and arguably dishonest.

 

[USAFRet]

I would expect that your drive could become "laggy" when hitting those Current Pending and Uncorrectable sectors. An Uncorrectable Sector Count of 0x2F67 corresponds to 12135 physical sectors, which is 97080 logical sectors. At the moment the drive has reallocated 9368 logical sectors.

BTW, the drive is still reporting a 100% normalised value for the Current Pending Sector Count and Reallocation Event Count, even though the raw values are 2048 and 1170, respectively. That's misleading, and arguably dishonest.

When two different systems, Windows 10 Pro and the Linux based NAS, report issues, and it is still under warranty....bye bye.
I have little patience to investigate or fix 'issues' when the thing is still in the beginning stages of the warranty period.

Awaiting on what Toshiba says.


If this was something far past the warranty, then things would be different.
I'd play with it a lot more.

 

[fzabkar]

It wasn't too long ago that WD set its threshold for SMART failure at 500 reallocations. Recently I saw a current WD model where this threshold was now about 20,000. Seagate's threshold has been in the tens of thousands for many years, and it would now appear that Toshiba has gone the same way. This trend would suggest that future HDD technology is projected to become very unreliable. :-(

 

[USAFRet]

It wasn't too long ago that WD set its threshold for SMART failure at 500 reallocations. Recently I saw a current WD model where this threshold was now about 20,000. Seagate's threshold has been in the tens of thousands for many years, and it would now appear that Toshiba has gone the same way. This trend would suggest that future HDD technology is projected to become very unreliable. :-(

Wow thats bad.

More capacity, crappier reliability.

 

[PiersJH]

I would expect that your drive could become "laggy" when hitting those Current Pending and Uncorrectable sectors. An Uncorrectable Sector Count of 0x2F67 corresponds to 12135 physical sectors, which is 97080 logical sectors. At the moment the drive has reallocated 9368 logical sectors.

BTW, the drive is still reporting a 100% normalised value for the Current Pending Sector Count and Reallocation Event Count, even though the raw values are 2048 and 1170, respectively. That's misleading, and arguably dishonest.

What's your verdict with my drives based on that information?

 

[fzabkar]

@PiersJH, I see nothing in your SMART reports that would concern me.

 

[PiersJH]

@PiersJH, I see nothing in your SMART reports that would concern me.

Thank you. I really do appreciate you taking the time to break down the values and explain why SMART reporting tools (in decimal) are reporting incorrectly.