From owner-cvs-src@FreeBSD.ORG Fri Mar 31 10:30:29 2006 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B02C16A400; Fri, 31 Mar 2006 10:30:29 +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 D842A43D46; Fri, 31 Mar 2006 10:30:28 +0000 (GMT) (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 CE09D46BE8; Fri, 31 Mar 2006 05:30:27 -0500 (EST) Date: Fri, 31 Mar 2006 10:30:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Joao Barros In-Reply-To: <70e8236f0603310129r5fe4e3a4qd9cb329c768860cc@mail.gmail.com> Message-ID: <20060331102745.D88223@fledge.watson.org> References: <200603302104.k2UL4qF7086165@repoman.freebsd.org> <20060331080654.GB776@turion.vk2pj.dyndns.org> <20060331090421.I9972@fledge.watson.org> <70e8236f0603310129r5fe4e3a4qd9cb329c768860cc@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Peter Jeremy , src-committers@freebsd.org, "Christian S.J. Peron" , cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Mar 2006 10:30:29 -0000 On Fri, 31 Mar 2006, Joao Barros wrote: >>> My sole concern with this is that this means that syslogd will keep trying >>> to write to the full filesystem - and the kernel will log the attempts to >>> write to a full filesystem. Whilst there's rate limiting in the kernel, >>> this sort of feedback loop is undesirable. >> >> What I'd like to see is an argument to syslogd to specify a maximum full >> level for the target file system. Log data is valuable, but being able to >> write to /var/tmp/vi.recover is also important. syslogd -l 90% could >> specify that sylogd should not write log records, perhaps other than an >> "out of space record" to a log file on a file system with >=90% capacity. >> This prevents the kernel from spewing about being out of space also. The >> accounting code does exactly this, for identical reasons. > > I was in bed last night and thought about this but also remembered > something: imagine a very busy syslog machine, won't this "free space check" > be a burden? I have a syslog machine at work that can fill up 30GB of disk > in less than 2 hours and it's busy as it is :-) The solution as you > correctly point out is it being optional. Take in consideration that > checking by percentage can be tricky. On a very large disk that's > inefficient, on a small one dangerous. Maybe a choice between percentage and > real space is best. > > Does the kernel automatically starts complaining about out of space at 90%? > If so that undermines my previous suggestions, but the questions remain ;-) The cost to check for free space is the cost of a fstatfs() system call on the file descriptor of the log file. This should be handled without touching the disk, so while it's not a cheap system call compared to, say, getpid(), as it acquires locks and enters VFS, it's a lot cheaper than any disk I/O operation. Optional is good, if only because sometimes people do actually want logging to fill the disk, and that's been the behavior historically :-). While "how much free space is there" is a somewhat semantically problematic concept, in practice you can divide available blocks by total blocks and get a decent (and workable) approximation. At least, if you get the signed and unsigned types right, which in the past the accounting system has not :-). Robert N M Watson