> > 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.
> > Thanks,
> > - Ryan
> Definitely agree. I view there as being two entirely
> technology items:
> (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.
First, if smartmontools is GPL, it would _have_ to remain
separate from FMA anyway, right? I mean, one couldn't integrate
it in terms of linking or mingling code, best one could do would be popen()
and parse the output.
But I also agree that making the info available in human-readable form
with minimal interpretation is desirable, but doing so should not
be permitted to impact or cause confusion with FMA functionality.
And second, blastwave has a smartmontools package already; which is
to say, they already have it ported to Solaris 8 and later (version 5.36,
presumably for both SPARC and x86).
(In fact, I've used it on my SB2K running SX, not long after I got it 2nd-hand,
and again not long after getting some larger and younger FC disks for it; it
was nice to know hours of operation, error history, or number of power
cycles or whatever such info it could provide, which more or less
corroborated what the eBay seller of the used drives claimed, as I recall.)
Unless one of those proposing this new port is the blastwave package
maintainer shown at the location above, perhaps they ought to talk to
him and try to learn whatever they can from what he's done already.
And if it's integrated, perhaps the blastwave folks could be asked to add
a note that it's bundled with build xx or later, so people don't end up with
two copies running and possibly stepping on each other.
This message posted from opensolaris.org