Mike Gerdts wrote:
On 5/25/07, Garrett D'Amore <[EMAIL PROTECTED]> wrote:
Again, I think there is historical value here. (Of two kinds. First
there is the historical practice of having the data in the logs.
Second, there is value in being able to look back in time and see when
link came up, or was dropped.) Plus it allows an administrator to see
link status changes in real-time by doing: tail -f /var/adm/messages
(without having to write a special tool to monitor dladm.)
In practice, it is somewhat common to scrape logs for this type of
information. However, I have always seen it as a sub-optimal work
around.
Yes, it is suboptimal. But sysadmins use the tools at hand.
If we want to further suppress link status notices in the log, at least
with this change there will be only one place to do so (in the mac
layer) rather than in all the drivers.
For the moment I think having *some* record of *changes* is useful.
(You won't see a link that is down continuing to report multiple entries
in the log, unless there is something seriously wrong with the PHY where
it keeps establishing and dropping link. But that's a sign of a serious
problem that deserves logging anyway.)
Is it more appropriate (longer term) to integrate with FMA and allow
FMA configuration to handle the logging, eventual SNMP traps, etc.?
Getting the logging to one place is likely a good first step in this
direction.
That may be. But as you say, by getting it happening in Nemo now, we
can easily change the policy later.
One thing that I haven't seen with fault management (haven't looked
too hard either) is the notion that things can fix themselves. In the
case of a link failure it is somewhat common for the fault to fix
itself (e.g. switch was reset).
I haven't spent too much with FMA yet. The ddi_dev_report_fault() that
was used by hme had this notion. Of course, the hme implementation of
ddi_dev_report_fault() events a bit incomplete.
-- Garrett
_______________________________________________
networking-discuss mailing list
[email protected]
