Custom Query (1565 matches)

Both of these disks report taking 255 minutes to complete the long (extended) self-test:

0 root@monkey:~# smartctl -t long /dev/sdd
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 255 minutes for test to complete.
Test will complete after Tue Nov 22 04:31:37 2011

Use smartctl -X to abort test.
0 root@monkey:~# smartctl -t long /dev/sdb
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF OFFLINE IMMEDIATE AND SELF-TEST SECTION ===
Sending command: "Execute SMART Extended self-test routine immediately in off-line mode".
Drive command "Execute SMART Extended self-test routine immediately in off-line mode" successful.
Testing has begun.
Please wait 255 minutes for test to complete.
Test will complete after Tue Nov 22 04:31:41 2011
0 root@monkey:~# 

However, their internal firmware believes that the amount of time taken varies significantly (686 and 506 minutes respectively, if i'm reading this output correctly):

0 root@monkey:~# smartctl -a /dev/sdb | egrep -A1 'START OF INFO|Total time'
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD2003FYYS-02W0B0
--
Total time to complete Offline 
data collection:                 (30360) seconds.
0 root@monkey:~# smartctl -a /dev/sdd | egrep -A1 'START|Total\ time'
=== START OF INFORMATION SECTION ===
Device Model:     WDC WD2002FYPS-02W3B0
--
Total time to complete Offline 
data collection:                 (41160) seconds.
0 root@monkey:~# 

This makes me think that the report of 255 minutes is flawed (maybe capped by an unsigned char or something?)

This is using stock debian squeeze:

0 root@monkey:~# uname -a
Linux monkey 2.6.32-5-vserver-amd64 #1 SMP Mon Oct 3 06:23:01 UTC 2011 x86_64 GNU/Linux
0 root@monkey:~# smartctl --version
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

smartctl comes with ABSOLUTELY NO WARRANTY. This is free
software, and you are welcome to redistribute it under
the terms of the GNU General Public License Version 2.
See http://www.gnu.org for further details.

smartmontools release 5.40 dated 2009-12-09 at 21:00:32 UTC
smartmontools SVN rev 3124 dated 2010-07-12 at 19:21:00
smartmontools build host: x86_64-unknown-linux-gnu
smartmontools build configured: 2010-12-26 11:52:46 UTC
smartctl compile dated Dec 26 2010 at 11:53:03
smartmontools configure arguments:  '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-initscriptdir=/etc/init.d' '--with-docdir=/usr/share/doc/smartmontools' '--enable-drivedb' '--enable-savestates' '--enable-attributelog' '--with-savestates=/var/lib/smartmontools/smartd.' '--with-attributelog=/var/lib/smartmontools/attrlog.' '--with-selinux' 'CXXFLAGS=-g -O2' 'LDFLAGS=' 'CPPFLAGS=' 'CFLAGS=-g -O2 -fsigned-char -Wall -O2'
0 root@monkey:~# 

lm_sensors has the ability to display sensor data from multiple sources. Unfortunately there is not a module that will display HD temperature data. Instead the lm_sensors documentation says that the smartmontools package should be used to gather and display this data. While the smart tools are certainly very nice as a separate package, it would be very helpful if the smart data was integrated with lm_sensors so that the HD temperature could be displayed alongside all of the other sensor data. For example there are numerous tools that have been compiled with the sensor libraries (EG, desktop applets, SNMP agents, etc), and it would be very helpful if HD temperature data was available through those channels alongside all of the other sensor readings, instead of isolated from them.

I am making the same request to the lm_sensors developers

Thanks

I love the selective self tests feature (-t select,min-max/next/cont[+SIZE]). The long tests just take too long. However I can't get it to work right with smartd.

My configuration is this:

• smartmontools version 6.2

• smartd started with --savestates=/var/lib/smartd/ and verified that state files actually appear in that location

• smartd.conf with -a -s c/../.././17 for all disks

My issues are these:

• when I -t select,min-max a disk (to get things started), this info usually does not make it into the state files. And without the state files nothing works as my WDC disks don't seem to keep the data across reboots

• after adding selective-test-last-start/end manually to the state files, things *seem* to work for a while. But it seems to forget the range size after a couple of days, probably when it reaches the end of the disk?

• one of the disks is a SSD (Crucial M4 64G), and I did a -t select,0-max on it in an attempt to make the cont check always check the entire thing. What happens instead is that smartd actually checks nothing (0-0) every time and the last start/end vanishes from the state file. (I'm aware I should just make an extra config entry for the SSDs that use long tests as they don't take long on SSDs.)

• If possible I'd like to be able to specify the SIZE directly in smartd.conf the same way it's possible to do on the command line (-t select,cont+SIZE). Ideally this should also remove the need of running the first select test manually.

• It would be cool if SIZE could be specified as a percentage, so for example a DEFAULT entry that checks 5% of a disk could be made regardless of disk sizes.