cvs commit: src/usr.sbin/syslogd syslogd.c
rwatson at FreeBSD.org
Fri Mar 31 10:30:29 UTC 2006
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
More information about the cvs-src