http://oss.sgi.com/bugzilla/show_bug.cgi?id=936
--- Comment #4 from Ken McDonell <kenj@xxxxxxxxxxxxxxxx> 2012-12-11 18:02:33
CST ---
OK, I've dug a little deeper.
The original rule was falling some_inst ... the semantics of this are a little
odd, namely the some_inst ... has a singular boolean value, so falling can only
be true when some_inst ... transitions from true to false ... I don't think
there is any robust binding of %v (1 is the best you could get) or %i (_all_
the instances conspire to make some_inst false, and we don't have enough
history to figure which of the instances were true at the last sample).
Although this rule is syntactically correct, the semantics are sufficiently
unusual that I don't propose smacking pmie to try and get a better answer
(because I don't thing there is one, especially when one considers the range of
operators that could be involved in a boolean expression following the
"falling".
I suspect the intent of the rule may be more accurately captured by:
some_inst falling match_inst ... filesys.full > 40
which would be true (and %i well defined) when some filesystem falls below 40%
full. It turns out that the following is semantically equivalent if you
prefer:
some_inst match_inst ... falling filesys.full > 40
The other example of rising some_inst ... sort of works _by accident_ as we can
find the instances that make some_inst true and all instances must have been
false at the previous sample. Again a better representation of the rule would
probably be:
some_inst rising match_inst ... filesys.full > 50
Unless someone objects over the next week, I plan to close out this bug.
--
Configure bugmail: http://oss.sgi.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
|