DonLogan wrote in news:u8q8441q5u0k6jajsvei5b6mo08epq06m6@4ax.com
> "Squeeze" <rubberduck@duckies.au> wrote:
>
> snip
> >
> > > and do the values display as billions or roll over at 999 million?
> >
> > I have no idea where that comes from.
> Rae Read Error Rate & Reallocated Sector Count was 160,374,848
Of course it was.
> now is 49,678,669 , so looks like it rolls over at 999,999,999
Or that it is not a counter in the sense that it can only go up.
And it's a binary number, so no, a nice decimal number is not very likely.
Now think this over for a moment, would a number roll over without the threshold getting exceeded? What would the point of such
theshold be?
What is the number now? And what is it 5 minutes later.
What is it after powerup from cold.
> >
> > >
> > > SMART says OK, but it isn't.
> >
> > Yes it is.
>DonLogan wrote in news:u8q8441q5u0k6jajsvei5b6mo08epq06m6@4ax.com
>> "Squeeze" <rubberduck@duckies.au> wrote:
>>
>> snip
>> >
>> > > and do the values display as billions or roll over at 999 million?
>> >
>> > I have no idea where that comes from.
>
>> Rae Read Error Rate & Reallocated Sector Count was 160,374,848
>
>Of course it was.
redudndantant
>
>> now is 49,678,669 , so looks like it rolls over at 999,999,999
>
>Or that it is not a counter in the sense that it can only go up.
was that a question?
i can think of several answers, but if you know a little help please
>And it's a binary number, so no, a nice decimal number is not very likely.
as long as its a number
>Now think this over for a moment, would a number roll over without the threshold getting exceeded?
no - bad idea
>What would the point of such theshold be?
what's the threshold?
i see 4 numbers - w x y z
I'm quoting z
>
>What is the number now? And what is it 5 minutes later.
>What is it after powerup from cold.
yes, i can do that but isn't this old ground?
happy to record if it really means something and nobody knows.
(now 71,095,553 - so gone up this time - haven't rebooted)
>
On Mon, 02 Jun 2008 17:44:33 -0400, DonLogan <navajo@neonfeather.com>
put finger to keyboard and composed:
>"Squeeze" <rubberduck@duckies.au> wrote:
>
>snip
>>
>>> and do the values display as billions or roll over at 999 million?
>>
>>I have no idea where that comes from.
>
>Rae Read Error Rate & Reallocated Sector Count was
>160,374,848
>now is
>49,678,669
>so looks like it rolls over at 999,999,999
I don't think you meant "Reallocated Sector Count". That figure grows
until the drive fails.
As for the "Raw Read Error Rate", it's difficult to understand how
Seagate uses this attribute. Seagate's FAQ states that ...
"The SMART values that might be read out by third-party SMART software
are not based on how the values may be used within the Seagate hard
drives. Seagate does not provide support for software programs that
claim to read individual SMART attributes and thresholds.
The individual attributes and threshold values are proprietary and we
do not offer a utility that will read out the values."
The "Seek Error Rate" value is also a strange one. My testing suggests
that it reflects a seek count, not an error, and not a rate:
Franc Zabkar wrote in news:d4s944t2ccpte2udu9hufpnqhng65mg7rm@4ax.com
> On Mon, 02 Jun 2008 17:44:33 -0400, DonLogan navajo@neonfeather.com put finger to keyboard and composed:
> > "Squeeze" <rubberduck@duckies.au> wrote:
> >
> > snip
> > >
> > > > and do the values display as billions or roll over at 999 million?
> > >
> > > I have no idea where that comes from.
> >
> > Rae Read Error Rate & Reallocated Sector Count was
> > 160,374,848
> > now is
> > 49,678,669
> > so looks like it rolls over at 999,999,999
>
> I don't think you meant "Reallocated Sector Count". That figure grows
> until the drive fails.
>
> As for the "Raw Read Error Rate", it's difficult to understand how
> Seagate uses this attribute. Seagate's FAQ states that ...
>
> "The SMART values that might be read out by third-party SMART software
> are not based on how the values may be used within the Seagate hard
> drives. Seagate does not provide support for software programs that
> claim to read individual SMART attributes and thresholds.
>
> The individual attributes and threshold values are proprietary and we
> do not offer a utility that will read out the values."
> The "Seek Error Rate" value is also a strange one.
What "Seek Error Rate".
What exactly did you not understand in the lines from Seagate that you just quoted?
Let me give you some reflection on that, here is what Seagate writes:
"The SMART values that might be read out by third-party SMART
software are not based on how the values may be used within the Seagate
hard drives. Seagate does not provide support for software programs
that claim to read individual SMART attributes and thresholds."
Maybe you should read it sometime in between when you
are not occupied by your Franc Zabkar promotion.
I notice that there is an abrupt increase in the raw Seek Error Rate
value at row 25, from 0x052E0E39C161 to 0x052F0E39FD21. This suggests
that the uppermost 4 nibbles are not part of the seek count, but
instead reflect some other event or attribute. If we take only the
lower 32 bits, then we get an average of about 600msec between seeks
over the last 3 months of the drive's life, which makes much more
sense.
Maybe the uppermost 16 bits represent the seek error count and the
lowermost 32 bits the total seek count ??? However, this still doesn't
explain why the "worst" normalised value for the Seek Error Rate
attribute is less than the current normalised value. Furthermore, my
13GB drive belongs to an earlier model family, so the SMART attributes
may be encoded differently to those of later models.
- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.
Franc Zabkar wrote in news:5jjb44550gjg1bv0v3l986ts53lglhhs80@4ax.com
> On Tue, 03 Jun 2008 17:23:30 +1000, Franc Zabkar <fzabkar@iinternode.on.net> put finger to keyboard and composed:
>
> > The "Seek Error Rate" value is also a strange one. My testing suggests
> > that it reflects a seek count, not an error, and not a rate:
> >
> > http://groups.google.com/group/micro...c63d875bfaf0d4
> > http://groups.google.com/group/micro...eb3d937a08e2e3
> >
> > However, if I look at the raw *totals* I get ...
> >
> > http://www.users.on.net/~fzabkar/SmartUDM/13GB.RPT
> >
> > Seek Error Rate 052E0E3000ECh
> > Power On Hours Count 0000000026C7h
> >
> > If I divide "power on hours" by the "seek error rate" (aka seek count
> > ???), ...
> >
> > http://www.google.com/search?hl=en&q...ds&btnG=Search
> >
> > ... then I get 6.3 microseconds per seek, which seems absurd.
> >
> > Here is a spreadsheet of the last 3 month's of SMART data for my
> > failing 13GB Seagate hard drive:
> >
> > http://www.users.on.net/~fzabkar/Sma...SMART_13GB.XLS
>
> I notice that there is an abrupt increase in the raw Seek Error Rate
> value at row 25, from 0x052E0E39C161 to 0x052F0E39FD21. This
> suggests that the uppermost 4 nibbles are not part of the seek count,
> but instead reflect some other event or attribute. If we take only the
> lower 32 bits, then we get an average of about 600msec between seeks
> over the last 3 months of the drive's life, which makes much more sense.
>
> Maybe the uppermost 16 bits represent the seek error count and the
> lowermost 32 bits the total seek count ??? However, this still doesn't
> explain why the "worst" normalised value for the Seek Error Rate
> attribute is less than the current normalised value. Furthermore, my
> 13GB drive belongs to an earlier model family, so the SMART attributes
> may be encoded differently to those of later models.
Perhaps you should re-read those lines from the Seagate FAQ again, no?
To get a clue?
Are you one of those people as mentioned by Jim Hatfield in that SMART annex proposal, Franc?
"There is another class of device users, however, in the open source community. These people still do not
understand the differences, and they publish assertions and software claiming to tell you information that
you ‘need to know’ about your ‘own property’ that ‘the others’ don’t want you to know"
Christian Franke wrote in news:4846E7C0.3020105@t-online.de
> Squeeze wrote:
> > Christian Franke wrote in news:4842B029.7010104@t-online.de
> > > Squeeze wrote:
> > > > > or is there a standard?
> > > > Yes, the standard is that there is no real standard.
> > > > S.M.A.R.T attributes have been abandoned several specs ago already.
> > > >
> > > AFIAK, the attributes itself were never specified in any ATA standard.
> > > The last spec of the attribute data format was in the last ATA-3 draft
> > > from 1997.
> >
> > There is a proposal (e05148r0) by Jim Hatfield to add a SMART attributes list
> > as an informative annex to ATA8-ACS. It's about 3 years old already though.
> >
>
> I know ...
>
>
> > Allow me my Franc Zabkar moment:
> >
> > Quote
> > [...]
> > \Quote
> > from:
> > http://www.t13.org/Documents/Uploade...butesAnnex.pdf
> >
>
> ... because the above link and links to a more recent (3 part) version
> are already on the mentioned link list:
> > > See http://smartmontools.sourceforge.net...tml#references for
> > > further links.
So it appears, thanks.
> > >
> > > Christian
>
> The annex is still not included in the latest ATA-8 ACS draft 4c from
> Dec 2007.
>
> Christian
Re: read errors 
Linear Mode
