smart(8) Call for Testing

Chuck Tuffli chuck at tuffli.net
Thu Mar 29 12:46:21 UTC 2018


On Tue, Mar 27, 2018 at 10:01 AM, Charles Sprickman <spork at bway.net> wrote:
...
> I have to agree - this is kind of a prior-century tool as far as user
> friendliness it seems.
>
> What is the goal of this tool?  The main use for smartmontools seems to be
> to pluck information about the drive and act on some very specific items
> (for example, polling the “media wearout indicator” on SSDs is very useful,
> or read error rates on HDs.  But the smartmontools folks seem to spend a
> fair amount of time with putting drive data in their tool so that meaningful
> data is presented to the user.  Without that level of functionality out of
> the box, what’s the argument for this being in base vs. being a 3rd party
> tool that lives in the ports tree?  Think of the people that answer mailing
> list and forum questions when considering adding something like this to
> base…
>
> Again, maybe I’m just missing something or maybe this is here for a
> particular vendor that needs it or something.

After watching Michael's talk on diskctl and knowing a bit about the
differences between NVMe and ATA SMART data, I was curious how
something like the libsmart proposed in the talk could possibly work.
This tool was initially a test bed for those experiments, but it's
been cleaned up a bit and enhanced based on Michael's feedback.

The application works with the limited number of drive types we have,
and the hope was both to see how it fared on other folks drives as
well as get some feedback.

This work wasn't done for any particular vendor. The only hope was to
address a need voiced by someone in the *BSD community. Namely,
providing SMART values to other scripts and or applications. As far as
adding this to base, if the collective 'you' want it, awesome. If it
doesn't make sense, that's OK too.

--chuck


More information about the freebsd-fs mailing list