Robert Watson wrote:
On Thu, 24 May 2007, Gleb Smirnoff wrote:
A> W/o logging we have no way of really knowing. Before we were
possibly
A> accepting stuff we shouldn't have (spoofing and attacks). Now we may
A> drop stuff we perhaps should accept anyway. W/o logging diagnosing a
A> TCP problem was very difficult and would need a lot cooperation with
A> the PR submitter, if it was submitted at all. We normally only got a
A> report of TCP 'not working'. Figuring out what went wrong was pretty
A> much doing iterative shots into the dark and see if something
squeaks.
A>
A> With logging I want to make things much more obvious and simpler to
A> diagnose. Plus we get information in cases (from admins reading the
A> logs) that were totally lost in the noise or not even attempted to
A> be debugged.
A>
A> For our TCP maintainers (mostly I at the moment) and also 3rd parties
A> this makes TCP trouble diagnosis much more accessible. Based on a
A> log report and the OS name/version of the remote end we can pretty
A> much tell right away what went wrong. This saves an order of a
A> magnitude in debugging and fault analysis time. From many hours and
A> email round trips to mere minutes and one or two information
requests.
I completely understand that this logging is very important in the
process of refactoring the TCP code. I just think that the performance
impact should be measured before merging this logging to RELENG_6.
Kernel-sourced log messages result in an fsync() of log files the
message is written to, as syslogd feels that kernel messages are very
important and should go to disk as quickly and reliably as possible. As
a result, it's very desirable to rate limit (ideally no more than 1pps)
packet-generated log messages. I've been thinking of adding a spp
function to match ppsprint for things like kernel warnings about the
audit trail storage partition filling up, as one message a second is
still a lot.
kern.debug should not be automatically written and fsync()ed to disk.
All these TCP messages are sourced as kern.debug (except for the log_
in_vain variety with kern.info but that's something the user has to
explicitly enable).
--
Andre
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
