Seagate SMART, Raw Read Error Rate, Seek Error Rate
in [Storage]
|
Prev: The Windows 2000/XP USB 128 GB problem
Next: Hard drive failing? Reallocated Sector count warning
From: Folkert Rienstra on 2 Sep 2007 10:42 Arno Wagner wrote in message news:5jv010F1bpmbU1(a)mid.individual.net > Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: > > On 1 Sep 2007 07:29:59 GMT, Arno Wagner <me(a)privacy.net> put finger to > > keyboard and composed: > > > > Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: > [...] > > > > BTW, the Current Pending Sector Count of 1 reflects a sector that has > > > > been marked as bad by the OS. > > > > > > Not quite. It represents a sector that the drive has given up on, but > > > not yet been able to replace, because it was not written to it. > > > The OS does not factor into this. > > > Sorry, my statement was ambiguous. Maybe I should have written that > > "the Current Pending Sector Count of 1 coincides with a sector that > > has been marked as bad by the OS". > > Ok. > > > > A bad sector marked by the disk (and invisible to the OS) can > > > be counter as "reallocation event" or "reallocated sector > > > count". If these numbers start growing, something is seriously > > > wrong. > > > The numbers *are* growing. In fact they've grown from 34 to 119 in two > > years. I've been preparing to replace the drive for quite some time now. > > However, it's only in the last month or so that the drive has been making > > occasional noises, ie a very soft clink, probably from the voice coil posi- > > tioner. > Well. Personally I stop trustinf a disk around > 10 or so, unless they all happened in one burst. Which makes perfect sense if you are babblebot. > I have had one Maxtor disk with something like 200 reallocated sectors in > one event, which did run fine without any additional ones for three years > afterwards. Which obviously you only know by waiting for 3 years. > > So, it could be a problem with power (spikes, I would suspect), mecha- > nical shock/vibration or the like. Or the disk could have a problem. > I would replace that one. And subject the new disk to the same problem causes. Very good, babblebot. > Also, at some time the disk will run out of spare sectors. At this rate somewhere in the next century which is very bad, eh babblebot. > > > > > I suspect that the drive's controller is > > > > aware that it is bad, but it cannot relocate it until such time as the > > > > OS writes to it, thereby signalling that the data in that sector is no > > > > longer of any consequence. > > > > > > Yes. > > > > > > > FWIW, SeaTools Desktop v3.00 says the 13GB drive is OK, apart from one > > > > bad sector. > > > > > > One bad sector is no reason for concern. If they start to get more, > > > that would be. > > > > > > Arno > > > I now have a batch file that runs just prior to shutdown. Among other > > things, it captures SMART data and appends it to a log file. It'll be in- > > teresting to monitor the drive as it progresses toward total failure. :-) > > > BTW, these are the SMART data for my Fujitsu 6GB drive: > > http://www.users.on.net/~fzabkar/SmartUDM/6GB.RPT > > > Notice the raw value for "Power On Hours Count". > > > 0000008EF98Ah = 9369994 dec > > = 1069 years > > > In fact the figure appears to represent Power On Seconds. > This is a non-standardized field, AFAIK. Little you know. They all are, babblebot. > Bogus readings are no surprise here. As is your response. > > Arno
From: Folkert Rienstra on 2 Sep 2007 13:14 Arno Wagner wrote in news:5k06tjF1h73nU3(a)mid.individual.net > Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: > > On 2 Sep 2007 05:29:04 GMT, Arno Wagner <me(a)privacy.net> put finger to > > keyboard and composed: > > > > Previously Franc Zabkar <fzabkar(a)iinternode.on.net> wrote: > > > > > BTW, these are the SMART data for my Fujitsu 6GB drive: > > > > http://www.users.on.net/~fzabkar/SmartUDM/6GB.RPT > > > > > > > Notice the raw value for "Power On Hours Count". > > > > > > > 0000008EF98Ah = 9369994 dec > > > > = 1069 years > > > > > > > In fact the figure appears to represent Power On Seconds. > > > > > > This is a non-standardized field, AFAIK. Bogus readings are > > > no surprise here. > > > > > > Arno > > > I suspect that the figures aren't necessarily bogus, they may just > > need to be interpreted differently between manufacturers. > > That is what I meant. The raw values ace accurate, but the interpreted > figures are ofteh wrong. > > > That said, I haven't been able to find any detailed SMART > > documentation at any of the manufacturers' web sites. > > SMART is part of the ATA spec. You can find specs on the t13 comitte > website here: http://www.t13.org/ Which obviously you didn't bother to consult. > > Arno
From: Franc Zabkar on 2 Sep 2007 17:01 On Sun, 2 Sep 2007 09:11:58 -0700, "Eric Gisin" <gisin(a)uniserve.com> put finger to keyboard and composed: >"Franc Zabkar" <fzabkar(a)iinternode.on.net> wrote in message >news:b3mkd3t5rsfskeujhqmej21cu4igqs5lhm(a)4ax.com... >> >> I'm running Win98SE. While monitoring file accesses with Filemon (from >> SysInternals), I used Everest Home Edition (ver 2.20.405) to monitor >> the drive's SMART data. Every time I refreshed the SMART report (using >> F5), the Seek Error Rate figure increased by 10 points. However the >> Filemon capture window remained empty. How can a drive incur seek >> errors if there are no file accesses? I would think that the SMART >> data would be retrieved from the drive's RAM or flash EEPROM, so no >> actual seeks would be required. >> >SMART diagnostic I/O does not show up as Windows I/O. Understood, and that's essentially what I wrote. I merely used Filemon to confirm that Everest wasn't doing something else as well. So the question remains, why does SMART diagnostic I/O cause the Seek Error Rate figure to change? - Franc Zabkar -- Please remove one 'i' from my address when replying by email.
From: Folkert Rienstra on 2 Sep 2007 17:54 Franc Zabkar wrote in news:vd7md35mfhvt4p0qf73ah37k8tv853h8q2(a)4ax.com > On Sun, 2 Sep 2007 09:11:58 -0700, "Eric Gisin" gisin(a)uniserve.com put finger to keyboard and composed: > > "Franc Zabkar" fzabkar(a)iinternode.on.net> wrote in message news:b3mkd3t5rsfskeujhqmej21cu4igqs5lhm(a)4ax.com... > > > > > > I'm running Win98SE. While monitoring file accesses with Filemon (from > > > SysInternals), I used Everest Home Edition (ver 2.20.405) to monitor > > > the drive's SMART data. Every time I refreshed the SMART report (using > > > F5), the Seek Error Rate figure increased by 10 points. However the > > > Filemon capture window remained empty. How can a drive incur seek > > > errors if there are no file accesses? I would think that the SMART > > > data would be retrieved from the drive's RAM or flash EEPROM, so no > > > actual seeks would be required. > > > > > SMART diagnostic I/O does not show up as Windows I/O. > Understood, No, not really. > and that's essentially what I wrote. No, you didn't. > I merely used Filemon to confirm that Everest wasn't doing something > else as well. Like File IO maybe? > So the question remains, why does SMART diagnostic I/O cause the > Seek Error Rate figure to change? Maybe because it does "SMART diagnostic I/O" ? Just a calculated guess. What do you think. > > - Franc Zabkar
From: Franc Zabkar on 3 Sep 2007 02:20
On Sun, 2 Sep 2007 23:54:16 +0200, "Folkert Rienstra" <see_reply-to(a)myweb.nl> put finger to keyboard and composed: >Franc Zabkar wrote in news:vd7md35mfhvt4p0qf73ah37k8tv853h8q2(a)4ax.com >> On Sun, 2 Sep 2007 09:11:58 -0700, "Eric Gisin" gisin(a)uniserve.com put finger to keyboard and composed: >> > "Franc Zabkar" fzabkar(a)iinternode.on.net> wrote in message news:b3mkd3t5rsfskeujhqmej21cu4igqs5lhm(a)4ax.com... >> > > >> > > I'm running Win98SE. While monitoring file accesses with Filemon (from >> > > SysInternals), I used Everest Home Edition (ver 2.20.405) to monitor >> > > the drive's SMART data. Every time I refreshed the SMART report (using >> > > F5), the Seek Error Rate figure increased by 10 points. However the >> > > Filemon capture window remained empty. How can a drive incur seek >> > > errors if there are no file accesses? I would think that the SMART >> > > data would be retrieved from the drive's RAM or flash EEPROM, so no >> > > actual seeks would be required. >> > > >> > SMART diagnostic I/O does not show up as Windows I/O. > >> Understood, > >No, not really. > >> and that's essentially what I wrote. > >No, you didn't. > >> I merely used Filemon to confirm that Everest wasn't doing something >> else as well. > >Like File IO maybe? > >> So the question remains, why does SMART diagnostic I/O cause the > >> Seek Error Rate figure to change? > >Maybe because it does "SMART diagnostic I/O" ? >Just a calculated guess. What do you think. I think you are a putrefying dog turd that should go into my kill file. - Franc Zabkar -- Please remove one 'i' from my address when replying by email. |