[OmniOS-discuss] Granular control of fma modules

[Alex Wilson]

I’ve been recently trying to find a way to get disk-transport to ignore certain SMART values when deciding if a disk is going to fail — in particular, the Seek Error figures, which Seagate drives tend to make out to be a lot more significant than they really are, using a different scale to everyone else. I had a look through the code for disk-transport though and it doesn’t seem like it can do very much to help: the module itself is pretty dumb and just passes on errors from deeper down in the libraries it uses (where there is also no means of filtering out events).

The closest you can get is to use “fmadm acquit”, but it doesn’t seem to work for me — it clears out the fault that’s there for the moment, but doesn’t block it from coming back again, even though the man page suggests that it should. I guess this is because of disk-transport generating new UUIDs for each individual event rather than on the type of event? It’s a bit annoying.

I’d really like a disk-transport.conf var to say “ignore this particular type of SMART data” or “ignore it for these disks”. Maybe I should sit down and try to write some code for it...



On 19 Feb 2014, at 10:17 am, Anh Quach <anhquach at me.com> wrote:

> Is it possible to tell the disk-transport FMA module to ignore over-temperature on only a certain set of disks? 
> 
> I’m doing testing with some Seagate Constellation.3’s that seem to run hotter even at idle than the rest of my disks (39-44 C) and they are continually getting flagged for over temp. I know I can disable to the temp alert for that module but I don’t want to disable it for all disks, just these new Seagates. 
> 
> Thanks in advance!
> 
> -- 
> Anh Quach
> Sent with Airmail
> _______________________________________________
> OmniOS-discuss mailing list
> OmniOS-discuss at lists.omniti.com
> http://lists.omniti.com/mailman/listinfo/omnios-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20140220/a33e2778/attachment.html>