Welcome! This is the home page for the smartmontools package.
NEWS: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 originally derived from the Linux smartsuite package, and includes support for ATA/ATAPI-3 to -7 disks and SCSI disk and tape devices. It should run on any modern Darwin (Mac OSX), Linux, FreeBSD, NetBSD, OpenBSD, Solaris, OS/2, eComStation or Windows system. Alternatively, it can also be run from one of the bootable CDs or floppies containing smartmontools.
For printing convenience, everything except for the example output is on a single page.
There are different ways to get and install smartmontools. You can use any of the procedures below (the fourth is for Debian Linux only). Just after "Method 6" below are some instructions for trying out smartmontools once you have completed the installation. The INSTALL file contains additional information.
First Method (Redhat/Fedora Linux) - Install from the RPM filesu root (enter root password) rpm -ivh smartmontools-5.32.i386.rpmFor most users, this is all that is needed.
rpm -ivh --nodeps --force smartmontools-5.32.i386.rpm
rpm -e --noscripts smartmontools
tar zxvf smartmontools-5.32.tar.gz
cd smartmontools-5.32 ./configure make make install
Please note that the default installation location changed in versions >=5.31. If you don't pass any arguments to ./configure all files will reside under /usr/local to not interfere with files from your distribution. For more detailed information please also refer to the INSTALL document.
mkdir objdir cd objdir ../configure [options]
make DESTDIR=/home/myself/smartmontools-test installUse a full path: ~/smartmontools-test won't work.
Due to the new the SourceForge CVS architecture, the hostname for CVS access has changed from cvs.sourceforge.net to smartmontools.cvs.sourceforge.net. To update a copy of smartmontools checked out before 2006-05-12, change all the */CVS/Root files accordingly.
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@smartmontools.cvs.sourceforge.net:/cvsroot/smartmontools login (when prompted for a password, just press Enter) cvs -d:pserver:anonymous@smartmontools.cvs.sourceforge.net:/cvsroot/smartmontools co sm5
cvs -d:pserver:anonymous@smartmontools.cvs.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.36-1_i386.debIf you prefer to fetch the packages using apt, please read the instructions at backports.org.
To update your installation, click on the "Install or update now!" link on the Cygwin web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. Select smartmontools package in the "Utils" category.
The optional source package (smartmontools-*-src.tar.bz2) can be used to build both the Cygwin and the Windows binary packages on Cygwin. Refer to the file /usr/share/doc/Cygwin/smartmontools-*.README for details.
Or download and unzip the latest smartmontools Windows archive (*.win32.zip) from here.
More recent (and probably unstable) Windows test releases build from CVS snapshots are available here.
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.
The Windows package (see Method 6 above) provides preformatted man pages in *.html and *.txt format.
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 smartmontools package supports a number of different operating systems. Some of those operating systems are also distributed by multiple sources, and some of these maintain a database of bug reports. Here are links:
If you can provide additional distribution or OS-specific bug-database links, please send an email to smartmontools-support.
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.
It's not. Please read the end of the smartd man page (NOTES).
For example, in the message:
'Device: /dev/hda, SMART Attribute: 194 Temperature_Celsius changed from 94 to 93'
the value given is the 'Normalized' not the 'Raw' Attribute value (the
disk temperature in this case is about 22 Celsius). The
'-R' and '-r' Directives modify this behavior, so that
the information is printed with the Raw values as well, for example:
'Device: /dev/hda, SMART Attribute: 194 Temperature_Celsius changed from 94 [Raw 22] to 93 [Raw 23]'
Here the Raw values are the actual disk temperatures in Celsius. The
way in which the Raw values are printed, and the names under which the
Attributes are reported, is governed by the various
'-v Num,Description' Directives described in the smartd
man page. Please see the smartctl manual page for further
explanation of the differences between Normalized and Raw Attribute
values.
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.
For WD drives that exhibit this firmware bug, the relationship between
Attribute 9's raw value (H) and the time-stamps in the self-test log (h) are given by:
Let H = power on hours as shown by Attribute 9 (correct)
Let M = 60*H (power on minutes, correct)
Let m = M mod 65536 (incorrect value of power on minutes)
Let h = m/60 (incorrect value of power on hours, shown in self-test log)
Western Digital firmware initializes SMART Attributes 10, 11, and 199 after either 120 spin-ups or 8 power-on hours. Until that time, they have the uninitialized value 253.
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 or from the UBCD (Ultimate Boot CD, see below).
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 are some links:
Geocities Site,
IBM Site #1,
IBM Site #2
to an IBM 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.32.tar.gz.asc. Please verify these using the Smartmontools GPG Signing Key (current) Smartmontools GPG Signing Key (before 2005)
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.
Note (added 29 July 2004): starting with smartmontools (experimental) release 5.33, one can also access SMART data from drives behind 3ware controllers using the (character) devices /dev/twe0-15. This should work correctly even with older versions of the 3w-xxxx driver. One can also access SMART data from drives behind 3ware 9000-series controllers (3w-9xxx driver) using the (character) devices /dev/twa0-15.
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 Windows (using MinGW) versions of smartctl and smartd. Installation instructions for binary distributions can be found here and 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 ATTRIBUTE_NAME 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. Please do not submit a new drive for the database without checking to see if it is already in the database of the current smartmontools release version.
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 entire output from:
smartctl -a /dev/hd?
to smartmontools-database
as a plain-text ASCII email attachment (file type: ".txt"). 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.
Disk drives store data in blocks (sectors) of 512 bytes. Each 512 bytes has additional bytes appended to it (usually 40 to 60) which are used internally by the disk firmware for error checking/detection and correction. These are called ECC bytes.
Sometimes the data in a sector gets corrupted. This can happen because a speck of dust scratched the disk, or because the disk was powered down while writing data to that sector, or for other reasons. Usually the ECC bytes can be used to correct the corrupted data. However if the ECC bytes are inconsistent or can't be used to correct the bad data, then the 512 bytes of data are lost. Such a sector is called unreadable or uncorrectable.
If your disk has an unreadable sector, this means that some of your data can't be retrieved. You can force the disk to replace the unreadable sector with a spare good sector, but only at the price of losing the 512 bytes of data forever.
Disks with uncorrectable sectors can often be repaired by using the disk manufaturer's 'disk evaluation and repair' utility (see previous FAQ entry). 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.
Normally when an uncorrectable sector is found, the disk puts this onto a 'pending sector list' to indicate that it should be replaced with a spare good sector. However this replacement won't take place until either the disk can read the data on the bad sector, or is commanded to write new data to that bad sector.
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!).
A failing SMART_GET_VERSION call means that the device driver does not implement the I/O controls (see below) to access ATA SMART functionality.
Some Windows drivers for (S)ATA controllers are implemented as SCSI class drivers. This is usually the case for drivers which support RAID. Unfortunately, such drivers do not support the ATA specific SMART I/O controls.
This means that the device driver does not support the command SMART READ LOG. The message does not indicate a hard disk problem! It does also not mean that the disk itself does not support SMART logs. It may still be possible to read the logs with a Linux version of smartmontools run from some bootable CD.
To access ATA SMART functionality on Windows, smartmontools uses the I/O control calls SMART_RCV_DRIVE_DATA and SMART_SEND_DRIVE_CMD. These calls were available since Win95 OSR2. An example program from Microsoft can be found here (the related KB article 208048 is no longer available).
Starting with NT4, these calls do more restrictive parameter checks. In particular, the command codes for SMART READ LOG and ABORT SELF-TEST are not accepted. To perform these functions, smartmontools uses the undocumented functions SCSIOP_ATA_PASSTHROUGH (NT4) or IOCTL_IDE_PASS_THROUGH (2000/XP) instead. An example program using these calls can be found here, a related newsgroup thread is here.
Unfortunately, these undocumented functions are not implemented in most vendor specific ATA device drivers. Smartctl prints a "Function not implemented" message in this case.A new I/O control call IOCTL_ATA_PASS_THROUGH is available since Win2003 and XP SP2. It should be supported by most new drivers. Experimental code using this call was added 2006-04-27 and will appear in smartmontools release 5.37.
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
Note: an unofficial patch to libata that allows smartmontools to be used with the standard '-d ata' device type was posted to the linux kernel mailing list at the end of August 2004. The patch is included in the libata-dev patchset that can be applied to a recent Linux kernel (>= 2.6.9). With a SATA disk driven by a libata driver, smartmontools can now be used by specifying both the device type 'ata' and the SCSI device corresponding to this disk, for example, smartctl -i -d ata /dev/sda. The patch is still under development and it is probably best to make sure that the disk is idle before trying smartmontools.
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 SSRC 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 installed on your system:
man 8 smartctl man 8 smartd man 5 smartd.conf
Here are on-line versions of the smartmontools man pages:
smartctl manual page
smartd manual page
smartd.conf manual page
Note
that these are the manual pages for the current version
of smartmontools in the developers CVS repository; they might not
correspond to the (possibly older) version of smartmontools installed
on your system. So the manual pages installed on your system
should be regarded as definitive for your installation.
If you'd like to know more about SMART, then the following references may be helpful:
