From owner-cvs-all@FreeBSD.ORG Fri May 25 07:46:30 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5EDE416A400; Fri, 25 May 2007 07:46:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 32ECA13C458; Fri, 25 May 2007 07:46:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id B695346E14; Fri, 25 May 2007 03:46:29 -0400 (EDT) Date: Fri, 25 May 2007 08:46:29 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20070524092643.GC89017@FreeBSD.org> Message-ID: <20070525084450.H53865@fledge.watson.org> References: <200705182113.l4ILD2qb044650@repoman.freebsd.org> <20070521073544.GP89017@FreeBSD.org> <4654D011.5040309@freebsd.org> <20070524092643.GC89017@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, Andre Oppermann , cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/netinet tcp_syncache.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2007 07:46:30 -0000 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. Robert N M Watson Computer Laboratory University of Cambridge