> One feature that smartmontools provides that isn't available with FMA
> is ability to query SMART attributes on a disk. Smartmontools provides
> the smartctl utility to perform this operation, and I think that alone
> warrants it's inclusion in opensolaris.
> - Ryan
Definitely agree. I view there as being two entirely separate
(a) A set of tools and APIs to examine SMART data from drives.
These tools could be used manually by admins, and the APIs
can be used to build management stacks or telemetry modules for FMA.
(b) Things that consume the data, use it as telemetry, diagnose it,
and emit that diagnosis to a human or a higher-level mgmt stack.
I want the smartmontools in Solaris for (a). FMA already does (b), and
most importantly it integrates that telemetry with other i/o telemetry
data, in particular silent data corruption detected by ZFS, to form a
common diagnosis model. Smartmontools also offers a legacy form of
reporting, i.e. a bunch of syslog error messages and a weaker form of (b).
I am similarly ok with including smartmon's capability for (b), but we need
to make sure that it is off by default (i.e. not conflicting with the FMA
(b)), and that something sensible occurs if you enable it, or that we have
a documented procedure for enabling it in a way that doesn't mess up FMA
or confuse users who are interacting with it.
Mike Shapiro, Solaris Kernel Development. blogs.sun.com/mws/