Re: Raw Read Error Rate - Seagate and Fujitsu

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Raw Read Error Rate - Seagate and Fujitsu

Manfred Schwarb
Franc,

I did some greps over the drives database and looked for large values
of Raw_Read_Error_Rate, here my findings:

Maxtor (pre Seagate):
0xbb00068642
0x2c0004aeaa
0x3100060e09
0x45b0005ec97
0x35200077398
0x3f000563d1
0x3000692cb
0x49900051d09
0x1e0003d834

Hitachi:
0x100000002
0x30000000c
0x40000000f
0x100000004
0x300000003

Samsung:
0x1115f5e000f

Fujitsu:
0xc00030a14
0x240000511f
0x19000000b2
0x240000432f

Seagate:
largest value: 0xe859165


Am Dienstag, den 10.03.2009, 10:10 +1100 schrieb Franc Zabkar:
> I have attempted to make sense of Seagate's high Raw Read Error Rate
> values in the following Usenet discussion:
>
> http://groups.google.com/group/comp.sys.ibm.pc.hardware.storage/browse_thread/thread/b6eb8aa2476f9cac/c70401b7e63fed80#c70401b7e63fed80
>
> In Seagate's case, the lower 28 bits of the raw attribute value
> appear to reflect a sector count, not an error count.
>

I'm not completely convinced. In the entire database, I didn't find
any Seagate value larger than 0xe859165.
If your theory is correct, then the error indication must be in the
upper 20 bits, as the lower 28 bits are some sector count?

So either Seagate disks produce very rarely any raw read errors, or
there must be some other interpretation.

>From my list it seems Maxtor, Hitachi and Fujitsu have some
2 bytes / 4 bytes split.

Samsung has probably some 4 bytes / 2 bytes split, but I did find only
one single drive with a value larger than 0xffff.

Some vendor specs would really be handy ...

Thanks,
Manfred



> Some Fujitsu models appear to follow a similar scheme, although they
> use the lower 18 bits.
>
> -Franc Zabkar
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Smartmontools-support mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/smartmontools-support


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Smartmontools-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/smartmontools-support
Reply | Threaded
Open this post in threaded view
|

Re: Raw Read Error Rate - Seagate and Fujitsu

Franc Zabkar
Manfred,

Here is a discussion where the OP witnessed the raw value for
Seagate's Raw_Read_Error_Rate attribute "switching back to 0" after
counting to 250.000.000:
http://forums.seagate.com/stx/board/message?board.id=ata_drives&message.id=8732#M8732

The performance data for the OP's HD are consistent with my theory
that the lower 28 bits represent a sector count.

Maybe the max value is actually 250 million rather than 28 bits,
although the difference is moot in our case. The figure of 0xe859165
is 243,634,533 so we can't really be sure. I don't know what Seagate
does with the uppermost 20 bits. Could it be that the actual error
count is stored in some user inaccessible area rather than in the raw
value ??? IIRC, even those Seagate drives with bad cooked RRER values
do not have data in the uppermost nibbles.

Here are sorted RRER values for my FUJITSU MPF3204AT hard drive:
http://www.users.on.net/~fzabkar/SmartUDM/fuj_rrer.srt

The largest value is 0x3FF27. That's 20 bits. My testing with DOS
Debug confirms that this represents a sector count, as does similar
testing with my Seagate drives.

Your greps are interesting. However they would be more meaningful if
we could find some relationship between the uppermost bits and the
cooked values. Furthermore, a sector count that rolls over to zero
gives us no indication of the total number of sectors accessed during
the life of the drive. So should we interpret a Fujitsu RRER value of
0xc00030a14 as 12 read errors during the drive's lifetime or 12
errors in 0x30a14 sectors? In this case we would need to observe
whether the uppermost bits also roll over to 0 at the same time as
the lowermost bits, or whether they are monotonically increasing.

The Hitachi data are interesting. I don't know whether it is
significant that the lowest nibble is always greater than or equal to
the highest nibble.

The Samsung drive appears to display the RRER data in reverse. Do
good drives always show 0x0000 in the bottom 16 bits? If so, then
this would suggest that the bottom 4 nibbles may represent an error count.

Do the Maxtor counts roll over at 0x7FFFF ???

FYI, here are my daily SMART logs for my Seagate and Fujitsu drives:
http://www.users.on.net/~fzabkar/SmartUDM/SMART.zip

They span many months.

Just to confuse us further, my 13GB Seagate HD appears to interpret
the RRER data in a completely different way:
http://www.users.on.net/~fzabkar/SmartUDM/SMART_13GB.XLS

-Franc


At 09:36 AM 25/03/09, you wrote:

>Franc,
>
>I did some greps over the drives database and looked for large values
>of Raw_Read_Error_Rate, here my findings:
>
>Maxtor (pre Seagate):
>0xbb00068642
>0x2c0004aeaa
>0x3100060e09
>0x45b0005ec97
>0x35200077398
>0x3f000563d1
>0x3000692cb
>0x49900051d09
>0x1e0003d834
>
>Hitachi:
>0x100000002
>0x30000000c
>0x40000000f
>0x100000004
>0x300000003
>
>Samsung:
>0x1115f5e000f
>
>Fujitsu:
>0xc00030a14
>0x240000511f
>0x19000000b2
>0x240000432f
>
>Seagate:
>largest value: 0xe859165
>
>
>Am Dienstag, den 10.03.2009, 10:10 +1100 schrieb Franc Zabkar:
> > I have attempted to make sense of Seagate's high Raw Read Error Rate
> > values in the following Usenet discussion:
> >
> >
> http://groups.google.com/group/comp.sys.ibm.pc.hardware.storage/browse_thread/thread/b6eb8aa2476f9cac/c70401b7e63fed80#c70401b7e63fed80
> >
> > In Seagate's case, the lower 28 bits of the raw attribute value
> > appear to reflect a sector count, not an error count.
> >
>
>I'm not completely convinced. In the entire database, I didn't find
>any Seagate value larger than 0xe859165.
>If your theory is correct, then the error indication must be in the
>upper 20 bits, as the lower 28 bits are some sector count?
>
>So either Seagate disks produce very rarely any raw read errors, or
>there must be some other interpretation.
>
> >From my list it seems Maxtor, Hitachi and Fujitsu have some
>2 bytes / 4 bytes split.
>
>Samsung has probably some 4 bytes / 2 bytes split, but I did find only
>one single drive with a value larger than 0xffff.
>
>Some vendor specs would really be handy ...
>
>Thanks,
>Manfred
>
>
>
> > Some Fujitsu models appear to follow a similar scheme, although they
> > use the lower 18 bits.
> >
> > -Franc Zabkar
> >
> >
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Smartmontools-support mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/smartmontools-support


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Smartmontools-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/smartmontools-support
Reply | Threaded
Open this post in threaded view
|

Re: Raw Read Error Rate - Seagate and Fujitsu

Franc Zabkar
In reply to this post by Manfred Schwarb
 >Here are sorted RRER values for my FUJITSU MPF3204AT hard drive:
 >http://www.users.on.net/~fzabkar/SmartUDM/fuj_rrer.srt

 >The largest value is 0x3FF27. That's 20 bits.

Sorry, that's 18 bits, not 20.

-Franc


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Smartmontools-support mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/smartmontools-support