Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 31 Mar 2006 10:29:47 +0100
From:      "Joao Barros" <joao.barros@gmail.com>
To:        "Robert Watson" <rwatson@freebsd.org>
Cc:        Peter Jeremy <peterjeremy@optushome.com.au>, 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:  <70e8236f0603310129r5fe4e3a4qd9cb329c768860cc@mail.gmail.com>
In-Reply-To: <20060331090421.I9972@fledge.watson.org>
References:  <200603302104.k2UL4qF7086165@repoman.freebsd.org> <20060331080654.GB776@turion.vk2pj.dyndns.org> <20060331090421.I9972@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 3/31/06, Robert Watson <rwatson@freebsd.org> wrote:
>
> On Fri, 31 Mar 2006, Peter Jeremy wrote:
>
> > On Thu, 2006-Mar-30 21:04:52 +0000, Christian S.J. Peron wrote:
> >>  This change allows syslogd to ignore ENOSPC space errors, so that whe=
n the
> >>  filesystem is cleaned up, syslogd will automatically start logging ag=
ain
> >>  without requiring the reset. This makes syslogd(8) a bit more reliabl=
e.
> >
> > My sole concern with this is that this means that syslogd will keep try=
ing
> > 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 writ=
e 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 >=3D90% capacity.  This preve=
nts the
> kernel from spewing about being out of space also.  The accounting code d=
oes
> exactly this, for identical reasons.
>
> Robert N M Watson

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 ;-)

--
Joao Barros



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?70e8236f0603310129r5fe4e3a4qd9cb329c768860cc>