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
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
