cvs commit: src/sys/netinet tcp_syncache.c

Robert Watson rwatson at FreeBSD.org
Fri May 25 08:19:25 UTC 2007


On Fri, 25 May 2007, Andre Oppermann wrote:

>> 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).

I don't know the actual historical reason, but I've always assumed that the 
fsync'ing of kernel log data is a result of kernel output being used for 
system debugging, which tends to occur when the system is behaving in an 
unstable way.  Syncing the messages to disk means that the chances of the 
message not being there later due to being lost somewhere in the cache are 
greatly reduced -- i.e., on a system crash, you want debugging data until the 
last possible moment.  I think this is useful behavior, although it does make 
klog a less useful logging mechanism for high volume debug data -- for that we 
generally prefer KTR + ALQ.

My recommendation would simply be to stick this under pps and limit to 5 
warnings/sec or the like and stick with things basically as they are 
otherwise.  I would also suggest that these printfs be disabled in production 
systems, and solely used in the development branch (which is true now, but 
should remain true later).

Robert N M Watson
Computer Laboratory
University of Cambridge


More information about the cvs-all mailing list