From owner-freebsd-hackers  Wed Nov 19 12:22:05 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id MAA22218
          for hackers-outgoing; Wed, 19 Nov 1997 12:22:05 -0800 (PST)
          (envelope-from owner-freebsd-hackers)
Received: from misery.sdf.com (misery.sdf.com [204.244.210.193])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA22202
          for <hackers@freebsd.org>; Wed, 19 Nov 1997 12:21:59 -0800 (PST)
          (envelope-from tom@sdf.com)
Received: from tom by misery.sdf.com with smtp (Exim 1.73 #1)
	id 0xYGV8-0007Cm-00; Wed, 19 Nov 1997 12:13:30 -0800
Date: Wed, 19 Nov 1997 12:13:20 -0800 (PST)
From: Tom <tom@sdf.com>
To: Terry Lambert <tlambert@primenet.com>
cc: Don.Lewis@tsc.tdk.com, craig@ProGroup.COM, hackers@freebsd.org
Subject: Re: Partitioning suggestions?
In-Reply-To: <199711192005.NAA19787@usr08.primenet.com>
Message-ID: <Pine.BSF.3.95q.971119120516.25964H-100000@misery.sdf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


On Wed, 19 Nov 1997, Terry Lambert wrote:

> > > I)	Filling the disk up should not be catastrophic, even if it
> > > 	does occur.
> > 
> >   How can it not be catastrophic?  Think about a mail server.  It will
> > have to refuse e-mail, if there is no spool space.  That is catastrophic.
> 
> This is a graceful failure.  The mail remains enqueued on the

  I can't accept that idea of a "graceful" failure.  I don't know if there
are any "catastrophic" (ie. eaten e-mail, destroyed password
files, etc) failures in FreeBSD, due to full filesystems.  But the
so-called graceful failures are the real essence of this thread.  How do
you avoid them in the first place?

  You probably do not realize that most SMTP sending software lacks auto
retry.  As soon as Sendmail starts refusing connections because of lack of
space, expect your helpdesk to light up like a christmas tree.

...
> >   Who cares?  Many process run as root, so they are all competing for the
> > reserve.  Also, non-root processes can be critical too.
> 
> Set quotas.  The failure to set quotas is pilot error.

  Quotas don't apply to root.

> >   newsyslog can limit logs to a particular size.  It has no idea of how
> > much space might actually be available.  It can not avoid the issue,
> > perhaps only limit it.  It is only guarrenteed to avoid the issue, if
> > /var/log is a separate filesystem.
> 
> That doesn't guarantee it.  What if your FS fills up with PID files?

  What would be creating pid files in /var/log?

Tom