Dana H. Myers wrote:
Pete Bentley wrote:
Log file spam from a flapping link seems to me to be in the same
category as the spam you get from a disk with retriable errors...
It's irksome that it fills the log, but you wouldn't want to miss it.
A disk with retry-able errors, you might replace the disk. A flapping
link... you
might not be able to do anything other than ifconfig down that
interface or just
unplug it. So you end up with a log full of messages that something
isn't right
in the world, and there's really nothing you can do about it.
ifconfig down or replace it is _precisely_ the action you want to take
-- further, you really want to know that you need to take the action.
I really appreciate the argument that it's nice to have bread crumbs left
leading back to the scene of the crash, but it quickly turns into a
slippery
slope. There are a lot of potential log messages that would come in
handy
the one time you want them. I get a link status message every time I
boot
a system with one of the 'right' network adapters, and it indicates
nothing at all.
The problem I have is that there is legacy practice, and changing the
behavior now is something that needs to be carefully considered.
In over a decade of use, I can't think of any case where my log file was
spammed with so many link up/down messages that I lost data. Generally
when I've noticed more than a few of these messages, I've followed up
with either diagnosis at the switch, the port, the cable, or just done
"ifconfig down" an interface that isn't in use.
However, I can recount a number of times that I've looked back into the
logs to review negotiated link information, sometimes as far back as a week.
Now, there is a problem where NWAM is involved, in that many NIC drivers
will spam the log file when they try to retransmit a message, which
might just be a DHCP or somesuch. Usually after so many retries, they
will generate a new message to the log.
I think in those cases what I'd like to see is the message suppressed
unless there is an intervening change in the status of the link.
-- Garrett
Dana
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
