Date: Fri, 31 Mar 2006 10:30:28 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Joao Barros <joao.barros@gmail.com> Cc: src-committers@freebsd.org, "Christian S.J. Peron" <csjp@freebsd.org>, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src/usr.sbin/syslogd syslogd.c Message-ID: <20060331102745.D88223@fledge.watson.org> In-Reply-To: <70e8236f0603310129r5fe4e3a4qd9cb329c768860cc@mail.gmail.com> References: <200603302104.k2UL4qF7086165@repoman.freebsd.org> <20060331080654.GB776@turion.vk2pj.dyndns.org> <20060331090421.I9972@fledge.watson.org> <70e8236f0603310129r5fe4e3a4qd9cb329c768860cc@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060331102745.D88223>