Date: Fri, 25 May 2007 09:19:23 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Andre Oppermann <andre@freebsd.org> Cc: cvs-src@FreeBSD.org, Gleb Smirnoff <glebius@FreeBSD.org>, cvs-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c Message-ID: <20070525090951.F53865@fledge.watson.org> In-Reply-To: <46569762.6090801@freebsd.org> References: <200705182113.l4ILD2qb044650@repoman.freebsd.org> <20070521073544.GP89017@FreeBSD.org> <4654D011.5040309@freebsd.org> <20070524092643.GC89017@FreeBSD.org> <20070525084450.H53865@fledge.watson.org> <46569762.6090801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070525090951.F53865>