cvs commit: src/usr.sbin/syslogd syslogd.c

[Robert Watson]

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