From: Larry B. <lar...@vi...> - 2010-08-10 21:43:58
|
I have two servers with 8 SATA drives each and I periodically get emailed messages like the following: Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 112 to 110 Now the problem is that these messages just seem to move back and forth (i.e. 110 to 112, then 112 to 110, etc) and don't appear to accomplish anything. Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 110 to 111 Is there some way I can get rid of this "noise" so that messages that I receive are less frequent and more meaningful? Thanks in advance, Larry Bates vitalEsafe, Inc. |
From: Larry B. <lar...@vi...> - 2010-08-12 15:49:21
Attachments:
larry_bates.vcf
|
My apologies for the "html laden" earlier post I have two servers with 8 SATA drives each and I periodically get emailed messages like the following: Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 112 to 110 Now the problem is that these messages just seem to move back and forth (i.e. 110 to 112, then 112 to 110, etc) and don't appear to accomplish anything. Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure Attribute: 8 Seek_Time_Performance changed from 110 to 111 Is there some way I can get rid of this "noise" so that messages that I receive are less frequent and more meaningful? Thanks in advance, -- Regards, Larry Bates CTO vitalEsafe, Inc. |
From: <cf...@im...> - 2010-08-12 19:20:32
|
On Thu 12th Aug, 2010 at 09:09, Angela Kahealani seems to have written: >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev > > <sarcasm>Thanks for the SPAM!</sarcasm> > This is automatically added by the sourceforge mailing list software, isn't it? Nothing to do with any particular poster. If you object, I guess you have to complain to sourceforge or persuade the project to move elsewhere. (Not that I am any fan of the way sourceforge has changed recently but it is rather unfair to blame posters to the list for *this*.) Or am I missing something here? - cfr |
From: Gabriele P. <gp...@di...> - 2010-08-12 23:31:36
|
Hi Larry, On Thu, 2010-08-12 at 10:49 -0500, Larry Bates wrote: > My apologies for the "html laden" earlier post thanks for switching to plain text! > I have two servers with 8 SATA drives each and I periodically get emailed > messages like the following: > > Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure > Attribute: 8 Seek_Time_Performance changed from 112 to 110 > > Now the problem is that these messages just seem to move back and forth > (i.e. 110 to 112, then 112 to 110, etc) It's normal for attribute Seek_Time_Performance to change in both directions. Have a look at the following graph, which show a curve over time: http://munin.dipohl.de/pic/examples/smart_sda-week.png Much more volatile are Attributes like - Temperature_Celsius - Raw_Read_Error_Rate - Hardware_ECC_Recovered - ... Some examples here: https://supervision.globenet.org/munin/globenet.org/casserole.globenet.org-smartctl2_Temperature.html https://supervision.globenet.org/munin/globenet.org/casserole.globenet.org-smartctl2_RawReadErrorRate.html https://supervision.globenet.org/munin/globenet.org/casserole.globenet.org-smartctl2_HardwareECCRecovered.html > and don't appear to accomplish anything. Depending on your smartd configuration, you'll get reported changes of the *normalized* or the *raw* values. Read more about SMART Attributes here: http://sourceforge.net/apps/trac/smartmontools/wiki/TocDoc#SMARTAttributes http://sourceforge.net/apps/trac/smartmontools/wiki/FAQ#Attributes > Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure > Attribute: 8 Seek_Time_Performance changed from 110 to 111 > > Is there some way I can get rid of this "noise" If you don't want to monitor Attribute #8 configure your smartd monitoring this way: # The following line enables monitoring of the # ATA Error Log and the Self-Test Error Log. # It also tracks changes in both Prefailure # and Usage Attributes, apart from Attributes # 9, 194, and 231, and shows continued lines: # /dev/hdd -l error \ -l selftest \ -t \ # Attributes not tracked: -I 194 \ # temperature -I 231 \ # also temperature -I 9 # power-on hours ^^ a snippet from the manual page of smartd http://smartmontools.sourceforge.net/man/smartd.8.html#lbAI To get rid of messages concerning attribute #8 add option "-I 8" > so that messages that I receive are less frequent If you do not like voluminous syslog messages, a good choice of smartd configuration file directives might be: -H -l selftest -l error -f. (No attributes tracked) If you want more frequent information, use: -a. (also track attributes) You can set the smartd check intervals to a longer time. Default is 1800 sec (30 min). > and more meaningful? Compare the attributes normalized values with the thresh, listed in the attribute table. HTH, Gabriele |
From: Christian F. <Chr...@t-...> - 2010-08-23 19:54:04
|
Larry Bates wrote: > My apologies for the "html laden" earlier post > > I have two servers with 8 SATA drives each and I periodically get emailed > messages like the following: > > Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure > Attribute: 8 Seek_Time_Performance changed from 112 to 110 > > Now the problem is that these messages just seem to move back and > forth (i.e. > 110 to 112, then 112 to 110, etc) and don't appear to accomplish > anything. > > Aug 10 11:18:41 gfs01 smartd[3597]: Device: /dev/sdb, SMART Prefailure > Attribute: 8 Seek_Time_Performance changed from 110 to 111 > > Is there some way I can get rid of this "noise" so that messages that > I receive > are less frequent and more meaningful? > Not yet, but such a feature would make sense. I added a ticket: http://sourceforge.net/apps/trac/smartmontools/ticket/90 Thanks, Christian |