Red Hat Bugzilla – Bug 90896
please update SMART tools to smartmontools
Last modified: 2007-04-18 12:53:44 EDT
I have a hard drive (a Western Digital WD800JB) which always defaults to SMART being off. (I've downloaded WD's utilities, but I can't find any way to configure the drive to always default to enabling SMART.) Therefore, I have to explicitly run "smartctl -a" on the drive to enable SMART before the smartd daemon is launched (as smartd doesn't explicitly enable it). One solution to this would be to make the smartd daemon explicitly enable SMART on every device it can. However, it may be perfectly desirable to have a system in which some drives have SMART enabled, while some drives do not. Thus, I don't think making smartd always enable SMART is the best solution. What I've done instead is patch /etc/init.d/smartd so that if the file /etc/sysconfig/smart exists, it is sourced, and an explicit "smartctl -a" is executed for all devices listed in the SMART_ENABLE variable. I'll attach the patch for /etc/init.d/smartd, and a sample /etc/sysconfig/smart file. If you don't have a problem with this approach, please include it in the next release. If there's a different approach you'd like to see taken, suggest it, and I'll see what I can do.
Created attachment 91689 [details] patch for /etc/init.d/smartd this patch makes /etc/init.d/smartd aware of /etc/sysconfig/smart
Created attachment 91690 [details] sample /etc/sysconfig/smart file
Another solution is to use the smartmontools package: http://smartmontools.sourceforge.net/ The version of smartd in this package give the SMART ENABLE command when devices are registered. It also uses a config file /etc/smartd.conf that permits great flexibility in setup and configuration. So for example if you have a drive that you don't want to enable SMART on, you don't list it in the config file.
Okay, I've looked (albeit briefly) at the smartmontools package (thanks for the pointer Bruce), and it seems like the way to go. It would probably make sense to package smartmontools separately, rather than bundling it into kernel-utils. As it is now, the fact that kernel-utils contributes the SMART stuff means that someone who wants to build and install smartmontools themselves either has to rebuild kernel-utils with the SMART stuff removed, or they have to use --replacefiles when installing a smartmontools RPM. Thoughts?
Personally I am in favor of having smartmontools be a separate package from the kernel-utils package. But this may have ramifications that I am unaware of, and so I'm not sure if it is the "right thing" to do. Other people are more qualified to decide this than I am. Cheers, Bruce