Welcome! This is the home page for the smartmontools package.
The smartmontools package contains two utility programs (smartctl and smartd) to control and monitor storage systems using the Self-Monitoring, Analysis and Reporting Technology System (SMART) built into most modern ATA and SCSI hard disks. In many cases, these utilities will provide advanced warning of disk degradation and failure.
Smartmontools is derived from the smartsuite package, and includes support for ATA/ATAPI-3 to -7 disks and SCSI disk and tape devices. It should run on any modern Linux, FreeBSD, NetBSD, Solaris, and Windows system.
For printing convenience, everything except for the example output is on a single page.
There are four different ways to get and install smartmontools. You can use any of the first three procedures (the fourth is for Debian only). Just after "Method 4" below are some instructions for trying out smartmontools once you have completed the installation. The INSTALL file contains additional information.
First Method - Install from the RPM filesu root (enter root password) rpm -ivh smartmontools-5.1-18.i386.rpmFor most users, this is all that is needed.
rpm -ivh --nodeps --force smartmontools-5.1-18.i386.rpm
rpm -e --noscripts smartmontools
tar zxvf smartmontools-5.20.tar.gz
cd smartmontools-5.20 ./configure make make install
mkdir objdir cd objdir ../configure [options]
make DESTDIR=/home/myself/smartmontools-test installUse a full path: ~/smartmontools-test won't work.
One of the really cool things about CVS is that you can get any version of the code you want, from the first release up the the most current development version. And it's trivial, because each release is tagged with a name like RELEASE_5_1_18. You can see what the different names are by looking at the CVS repository. You'll see the tag names in the little scroll window where it says "Show only files with tag". All you need to do to get the latest development code is (but note that the development code may be unstable, and that the documentation and code may be inconsistent):
cvs -d:pserver:anonymous@cvs.smartmontools.sourceforge.net:/cvsroot/smartmontools login (when prompted for a password, just press Enter) cvs -d:pserver:anonymous@cvs.smartmontools.sourceforge.net:/cvsroot/smartmontools co sm5
cvs -d:pserver:anonymous@cvs.smartmontools.sourceforge.net:/cvsroot/smartmontools co -r RELEASE_5_1_16 sm5
This will create a subdirectory called sm5/ containing the code. Go to that directory, build, and install:
cd sm5 ./autogen.sh ./configure make make install
cd sm5 cvs up -r RELEASE_5_1_18
cd sm5 cvs up -A
dpkg -i smartmontools_5.1.18-1.agx0_i386.debBut the preferred method is to add the following line to your /etc/apt/sources.list:
deb http://honk.physik.uni-konstanz.de/~agx/linux-i386/debian smartmontools/and type
apt-get update && apt-get install smartmontoolsthis will automatically download and install the package.
If you want to manually install it (not recommended because, among others, you lose the ability to update and uninstall it), download the latest Cygwin package (*-cygwin.tar.bz2) from here, and type:
tar jxf smartmontools-5.30-1-cygwin.tar.bz2 -C /from a Cygwin shell.
man smartd.conf man smartctl man smartd /usr/sbin/smartctl -s on -o on -S on /dev/hda (only root can do this) /usr/sbin/smartctl -a /dev/hda (only root can do this)
Note that the default location for the manual pages are /usr/share/man/man5 and /usr/share/man/man8. If "man" doesn't find them, then you may need to add /usr/share/man to your MANPATH environment variable.
If a serious problem gets reported to us, it gets added to the WARNINGS file in smartmontools. So far there are only a few problem systems listed.
If your question is not here, please email me.
SourceForge is a free service, which supports a very large number of users and projects. Please check the SourceForge Site Status Page to see the maintenance schedule and to learn if SourceForge is experiencing unscheduled system outages or other problems.
Alternative mailing-list archives are provided by Gmane) and MARC (smartmontools-support and smartmontools-database).
First, search the support mailing list archives to see if your question has been answered. Instructions are in the following paragraph. If you don't find an answer there, then please send an email to the smartmontools-support mailing list. This is a moderated forum: you are not required to subscribe to the list in order to post your question.
To search the email archives, first go to the mailing list archive. In the top left corner you will see a search box: use Mailing List as the type of search. This tool works very well.
Note that from time to time SourceForge has mailing list problems and you'll get a message telling you that Either your mailing list name was misspelled or your mailing list has not been archived yet. If this list has just been created, please retry in 2-4 hours. If this happens, you'll have to try again later. Or use alternative (and usually up to date) email archives.
My plan is that smartmontools-5.x will support ATA/ATAPI-5 disks. Eventually, we'll do smartmontools-6.x to support ATA/ATAPI-6 disks, smartmontools-7.x for the ATA/ATAPI-7 standard, and so on. The "x" will denote revision level, as bugs get found and fixed, and as enhancements get added. If it's possible to maintain backwards compatibility, that would be nice, but I don't know if it will be possible or practical.
My research group at U. Wisconsin - Milwaukee runs a beowulf cluster with 600 ATA-5 and -6 disks (300 IBM and 300 Maxtor). We have more than 50 TB of data stored on the system. I also help out with a cluster at the Albert Einstein Institute that has 540 IBM ATA-6 disks (65 TB total). It's nice to have advanced warning when a disk is going to fail.
The raw SMART attributes (temperature, power-on lifetime, and so on) are stored in vendor-specific structures. Sometime these are strange. Hitachi disks (at least some of them) store power-on lifetime in minutes, rather than hours (see next question below). IBM disks (at least some of them) have three temperatures stored in the raw structure, not just one. And so on. If you find strange output, or unknown attributes, please send an email to smartmontools-support and we'll help you try and figure it out.
Please see the first section of the INSTALL file.
From Maxtor disks (99), (100), and (101). These are not used by Maxtor in SMART revision 5. They will be used in SMART revision 6, but the engineering group has not yet decided what to monitor with these Attributes.
On recent disks, Maxtor has started to use Attribute 9 to
store the power-on disk lifetime in minutes rather than hours. In this case, use
the:
-v 9,minutes
option to correctly display hours and minutes.
Some models of Fujitsu disks use Attribute 9 to store
the power-on disk lifetime in seconds. In that case, use the:
-v 9,seconds
option to correctly display hours, minutes and seconds.
There are three related problems with Maxtor's SMART firmware:
1 - On some Maxtor disks, the raw value of Attribute 9 (Power On Time) is supposed to be minutes. But it advances at an unpredictable rate, always more slowly than one count per minute. This is because when the disk is in idle mode, the counter stops advancing. This is only supposed to happen in standby mode. This will be corrected in Maxtor product lines released after October 2004.
2 - In Maxtor disks that use the raw value of Attribute 9 as a minutes counter, only two bytes (of the six available) are used to store the raw value. So it resets to zero once every 65536=2^16 minutes, or about once every 1092 hours. This is fixed in all Maxtor disks manufactured after July 2003, where the raw value was extended to four bytes.
3 - In Maxtor disks that use the raw value of Attribute 9 as a minutes counter, the hour time-stamps in the self-test and ATA error logs are calculated by right shifting 6 bits. This is equivalent to dividing by 64 rather than by 60. As a result, the hour time stamps in these logs advance 7% more slowly than they should. Thus, if you do self-tests once per week at the same time, instead of the time-stamps being 168 hours apart, they are 157 hours apart. This is also fixed in all Maxtor disks manufactured after July 2003.
The self-test log timestamps in many WD disks roll back to zero every 1092 hours (65536 minutes). This problem is due to a WD firmware bug. The power-on lifetime in hours is correctly stored in Attribute 9. However when the power-on lifetime is calculated for self-test log entries, the lifetime in minutes is put into a 16-bit register then divided by 60. The 16-bit register overflows and wraps around every 1092 hours.
A good listing of such utilities can be found here. Unfortunately most of these are for MS operating systems, but most can be run from an MS-DOS boot disk. Note: if you do run one of these utilities, and it identifies the meanings of any SMART Attributes that are not known to smartmontools, please report them to the mailing list above.
These utilities have an important role to fill. If your disk has bad sectors (for example, as revealed by running self-tests with smartmontools) and the disk is not able to recover the data from those sectors, then the disk will not automatically reallocate those damaged sectors from its set of spare sectors, because forcing the reallocation to take place may entail some loss of data. Because the commands that force such reallocation are Vendor Specific, most manufactuers provide a utility for this purpose. It may cause data loss but can repair damaged sectors (at least, until it runs out of replacement sectors).
smartd: Reading Device /dev/sdv modprobe: modprobe: Can't locate module block-major-65
This is because when smartd starts, if there is no configuration file, it looks for all ATA and SCSI devices to monitor (matching the pattern /dev/hd[a-t] or /dev/sd[a-z]). The log messages appear because your system doesn't have most of these devices.
The solution is simple: use the smartd configuration file /etc/smartd.conf to specify which devices to monitor.
Apparently some of the older SMART firmware on IBM disks can interfere with the regular operation of the disk. If you have this problem, here is an IBM DISK FIRMWARE UPGRADE that fixes the problem.
Since the smartmontools utilities run as root, you might be concerned about something harmful being embedded within them. Starting with release 5.19 of smartmontools, the .rpm files and tarball have been GPG signed. The tarball's fingerprint is given in a file on the release page with a name like smartmontools-5.20.tar.gz.asc. Please verify these using the Smartmontools GPG Signing Key
If you have a system that is showing signs of disk trouble (for example, it's unbootable and the console is full of disk error messages) it can be handy to have a version of smartmontools that can be run off of a bootable CD or floppy to examine the disk's SMART data and run self-tests. This is also useful if you want to run Captive Self-Tests (the -C option of smartctl ) on disks that can not easily be unmounted, such as those hosting the Operating System files. Or you can use this to run smartctl on computers that don't use Linux as the day-to-day operating system.
Here is a list of such bootable CDs:
Please let me know if there are others, and I will add them to this list.
From release 5.1-18, smartmontools fully supports 3ware SCSI RAID controllers that use ATA disks internally. To pass commands through the 3ware controller, use the smartmontools -d 3ware,N option or Directive.
3ware Linux device drivers (3w-xxxx) versions 1.02.00.036 and earlier do not return the SMART HEALTH STATUS (smartmontools -H) of the disks. In addition, the ENABLE AUTOMATIC OFFLINE and ENABLE ATTRIBUTE AUTOSAVE commands (smartmontools -o on and -S on) can not be passed through the driver to the disks. Later driver versions support all of these commands. You may:
To see if your system's 3w-xxxx driver has been patched, give the
command:
smartctl -H -S on -o on -d 3ware,? /dev/sd?
If you
have an unpatched kernel, you'll see warning messages prompting you to
patch the kernel.
The 3ware 3w-xxxx version 1.02.00.037 driver first appeared in kernel version 2.6.0-test5-bk11 on 24 September 2003 and in kernel version 2.4.23-bk2 on 3 December 2003. It was officially released on the 3ware web site on December 19, 2003 as part of their driver/firmware/utility package version 7.7.0.
Yes, finally it does. A windows port of smartctl 5.26 by Christian Franke was first checked in 2004/02/23 on CVS branch RELEASE_5_26_WIN32_BRANCH and has been merged to the CVS trunk later.
The Cygwin environment can be used to built both Cygwin and Native (MinGW, not depending on Cygwin) versions of smartctl and smartd. Installation instructions can be found here and here.
Alternatively, you can also run it from a bootable CD
Some code showing how to access SMART data under Windows 98, NT 4, 2000, and XP can be found here. Additional information from Microsoft can be found here. A related newsgroup thread (with pointers to additional documentation, etc.) is here.
It was non-standard. So with the move to GNU Autoconf and GNU
Automake it changed from 5.X-Y (where X and Y are one or more digits)
to 5.Y. Starting with the first release, and moving forward in time, the releases are
numbered as follows:
5.0-1,
5.0-2,
...,
5.0-45,
5.1-1,
...,
5.1-18,
5.19,
5.20,
...
If your drive is not in the database, then the names of the Attributes (displayed in the ID# column of smartctl -A /dev/hd?) and the format of the the raw Attribute values shown in the RAW_VALUE column may be incorrect. This is mostly cosmetic: the essential drive health monitoring/testing functionality of smartmontools does not depend upon the database.
If your drive is not in the database, pleaes check here to be sure that you are using the latest smartmontools release. Each new release has additional drives added to the database.
If your drive is not in the database of the current release,
to have it added to the database, first use the command:
smartctl -t short /dev/hd?
to run a short self-test on
the drive, and wait a few minutes for the test to complete. Then
email the output from:
smartctl -a /dev/hd?
to smartmontools-database
as an email attachment. The timestamp in the self-test log will help
us to determine whether Attribute 9 is being used to store the
lifetime in hours, minutes, or seconds.
If you need to use any of the vendor-specific display options (-v options) with the drive, or if any of the Attributes are behaving strangely, please include that information as well.
If your ATA drive supports self-tests, you should run them on a
regular basis, for example one per week:
smartctl -t long /dev/hd?
After the test has completed, you should examine the results with:
smartctl -l selftest /dev/hd?
If the drive fails a self-test, but still has 'PASS' SMART health status, this usually means that there is a corrupted sector on the disk, which can not be read. If the disk were able to read that sector of data, even once, then the disk firmware would mark the sector as 'bad' and then allocate a spare sectors to replace it. But if the disk can't read the sector even once, then it won't reallocate the sector, in hopes of being able, at some time in the future, to read the data from it. See BadBlockHowTo for instructions about how to force this sector to reallocate (Linux only).
The disk still has passing health status because the firmware has not found other signs of trouble, such as a failing servo.
Such disks can often be repaired by using the disk manufaturer's 'disk evaluation and repair' utility. Beware: this may force reallocation of the lost sector and thus corrupt or destroy any file system on the disk. See BadBlockHowTo for generic Linux instructions.
Some type of BIOS can check the SMART health status of a disk at bootup: the equivalent of 'smartctl -H /dev/hd?'. This one-time check on bootup is done if the BIOS SMART setting is set to 'ENABLE', and is not done if the setting is set to 'DISABLE'.
If this one-time check is done, and the disk's health status is found to be 'FAIL', then typically the BIOS will display an error message and refuse to boot the machine.
For the proper functioning of smartmontools, either BIOS setting may be used.
Fedora Core is distributed with a smartd configuration file /etc/smartd.conf that monitors the first IDE disk /dev/hda. If this device does not exist (or lacks SMART capability) you will get the error message above. Look in SYSLOG (/var/log/messages) for additional details about what is going wrong.
The solution: If your system has only SCSI disks, or has IDE disk(s) on a non-primary controller, just edit /etc/smartd.conf to reflect the correct location of the drive(s). Please also read the 'smartd.conf' man page for additional information.
Some Seagate disks store the current temperature Celsius in both the RAW and NORMALIZED Attribute 194 values, and the maximum lifetime temperature in Celsius in the WORST value. Since cooler is better, this means that in this case, lower NORMALIZED Attribute values are farther from failure, and that over time the WORST Attribute values get larger, not smaller (as with other Attributes).
The ATA error log is stored in a circular buffer, and the ATA specifications are unambiguous about how the entries should be ordered. This warning message means that the disk's firmware does not strictly obey the ATA specification regarding the ordering of the error log entries in the circular buffer. Smartmontools will correct for this oversight, so this warning message can be safely ignored by users. (On the other hand, firmware engineers: please read the ATA specs more closely then fix your code!).
Smartmontools for SCSI disks and tapes (including medium changers) is discussed on a separate page.
As for USB and FireWire (ieee1394) disks and tape drives, the news
is not good. They appear to Linux as SCSI devices but their
implementations do not usually support those SCSI commands needed by
smartmontools. The ieee1394 consortium recently certified the first external enclosure (containing
a ATA disk and a protocol bridge) as being compliant to the relevant
standards. Such devices have already been on the market for about 3
years and they tend to only support the bare minimum of commands
needed for device operation (i.e. SMART support is an unsupported
extra).
Smartmontools should work correctly with SATA drives under both Linux 2.4 and 2.6 kernels, if you use the standard IDE drivers in drivers/ide. If you use the new libata drivers, it won't work correctly because libata doesn't yet support the needed ATA-passthrough ioctl() calls. Jeff Garzik, the libata developer, says that this support will be added to libata in the future. When this happens, we'll add support to smartmontools for a new SATA/libata device type '-d sata'. Typically, to force an SATA disk to run using the standard (non-libata) drivers, you must use the BIOS to select "legacy mode" for the controller. If the IDE driver doesn't support your particular SATA controller, or the controller doesn't have a legacy interface, then only libata can be used. Unless the hard disk controller on the system motherboard is Intel, VIA or nVidia, standard IDE drivers may not work
The smartsuite code was originally developed as a Senior Thesis by Michael Cornwell at the Concurrent Systems Laboratory (now part of the Storage Systems Research Center), Jack Baskin School of Engineering, University of California, Santa Cruz. You can find some information about the original smartsuite project here: Press Release 1, Press Release 2, Press Release 3.
According to UCSC smartsuite is no longer maintained; the last release was in 2001.
Smartmontools was derived directly from smartsuite. It differs from smartsuite in that it supports the ATA/ATAPI-5 standard. So for example smartctl from smartsuite has no facility for printing the SMART self-test logs, and doesn't print timestamp information in the most usable way. The smartctl utility in smartmontools has added functionality for this (-q, -l selftest,-S, -T, -v and -m options), updated documentation, and also fixes small technical bugs in smartsuite. [One example: smartsuite does not actually use the ATA SMART RETURN STATUS command to find out the health status of a disk. It instead tries to infer this from the SMART Attribute values.] See the CHANGELOG file in CVS for a summary of what's been done. The smartd utility differs from the smartsuite smartd in major ways. First, it prints somewhat more informative error messages to the syslog. Second, on startup it looks for a configuration file /etc/smartd.conf, and if smartd finds this file, it monitors the list of devices therein, rather than querying all IDE and SCSI devices on your system. (If the configuration file does not exist, then it does query all IDE and SCSI devices.) Also, it's a well-behaved daemon and doesn't leave open file descriptors and other detrius behind. In addition, the smartmontools version of smartd can be instructed (via Directives in the configuration file) to monitor for changes in a number of different disk properties: the SMART status, failure or prefailure attributes going below threshold, new errors appearing in the ATA Error Log or the SMART Self-Test Log, and so on. smartd can also send an email warning or run a user-specified executable if it detects a problem with the disk.
The other principle difference is that smartmontools is an OpenSource development project, meaning that we keep the files in CVS, and that other developers who wish to contribute can commit changes to the archive. If you would like to contribute, please write to to smartmontools-support.
But the bottom line is that the code in smartmontools is derived directly from smartsuite and is similar. The smartsuite package can be found here.
If you are having trouble understanding the output of smartctl or smartd, please first read the manual pages:
man 5 smartd.conf man 8 smartctl man 8 smartd
If you'd like to know more about SMART, then the following references may be helpful:
