Setting APM through mpsX cards, and smartctl thoughts

Status
Not open for further replies.

mib

Dabbler
Joined
Sep 7, 2012
Messages
20
There is a great deal of lore sprinkled throughout the forums about using APM with drives that are connected via non-motherboard SATA interfaces. I recently stumbled upon what appears to be a really simple change, but before I file a bug/enhancement request, I wanted to get a quick sanity check here to make sure I'm not overlooking anything.

TL;DR The GUI-based APM settings are known not to work if drives are on the far side of a card like the 9211-8i. However, smartctl works very well indeed to both query APM state and to set it.

Detail I can set APM in the GUI storage settings all I want, but the drives won't reflect those settings. This is easy to verify via `sudo smartctl -g all /dev/daX`, which works swimmingly through the card.
Turns out that `sudo smartctl -s apm,128 /dev/daX` works too. I've verified this using the latest FreeNAS with an LSI 9211-8i running Phase 16 IT firmware and no on-card BIOS.

Question #1 Should the logic invoked by the GUI switch to using smartctl rather than the existing mechanism that doesn't work nearly as consistently? This is presumably camcontrol, but I haven't looked at the source to be sure.

Question #2 Would it be possible to better maintain the up-to-dateness of the smartctl database? The current version of smartctl is indeed 6.3, but the binary installed right now uses the 2014-07-26 database, ie the one the source release shipped with. The smartmontools folks frequently update the database (as of this writing, the latest db is 2015-02-02). While it makes sense for FreeBSD to just track the default db in the source distribution, it would make much more sense to me for FreeNAS to aggressively keep the smartctl database up to date. (I have a script that checks the db version on sourceforge daily, downloads it if it's newer, and then rebuilds smartmontools; it's quite easy.)

Are these items worth filing bugs for?

Thanks.
 

Ericloewe

Server Wrangler
Moderator
Joined
Feb 15, 2014
Messages
20,194
There is a great deal of lore sprinkled throughout the forums about using APM with drives that are connected via non-motherboard SATA interfaces. I recently stumbled upon what appears to be a really simple change, but before I file a bug/enhancement request, I wanted to get a quick sanity check here to make sure I'm not overlooking anything.

TL;DR The GUI-based APM settings are known not to work if drives are on the far side of a card like the 9211-8i. However, smartctl works very well indeed to both query APM state and to set it.

Detail I can set APM in the GUI storage settings all I want, but the drives won't reflect those settings. This is easy to verify via `sudo smartctl -g all /dev/daX`, which works swimmingly through the card.
Turns out that `sudo smartctl -s apm,128 /dev/daX` works too. I've verified this using the latest FreeNAS with an LSI 9211-8i running Phase 16 IT firmware and no on-card BIOS.

Question #1 Should the logic invoked by the GUI switch to using smartctl rather than the existing mechanism that doesn't work nearly as consistently? This is presumably camcontrol, but I haven't looked at the source to be sure.

Question #2 Would it be possible to better maintain the up-to-dateness of the smartctl database? The current version of smartctl is indeed 6.3, but the binary installed right now uses the 2014-07-26 database, ie the one the source release shipped with. The smartmontools folks frequently update the database (as of this writing, the latest db is 2015-02-02). While it makes sense for FreeBSD to just track the default db in the source distribution, it would make much more sense to me for FreeNAS to aggressively keep the smartctl database up to date. (I have a script that checks the db version on sourceforge daily, downloads it if it's newer, and then rebuilds smartmontools; it's quite easy.)

Are these items worth filing bugs for?

Thanks.

The updated SMART database might be worth a ticket.

Regarding #1, write it up with as much detail as you can and open a ticket. It'll probably be pushed back to 10.1, with the big rewrite, but it'll be on the devs' minds.
 
Status
Not open for further replies.
Top