Date: Wed, 19 Nov 1997 20:05:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tom@sdf.com (Tom) Cc: tlambert@primenet.com, Don.Lewis@tsc.tdk.com, craig@ProGroup.COM, hackers@freebsd.org Subject: Re: Partitioning suggestions? Message-ID: <199711192005.NAA19787@usr08.primenet.com> In-Reply-To: <Pine.BSF.3.95q.971119101124.25964D-100000@misery.sdf.com> from "Tom" at Nov 19, 97 10:19:49 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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 system attempting to deliver the mail; it's not lost. If you use the SMTP DSN extension, then you are even better off, but you don't *have* to in order for the failure to be graceful. Sendmail already has space limitation capabilities. The "-ob<x>[/<y>]" option allows refusal of messages when there are less than <x> blocks available on the queue FS. If the "/<y>" is specified, it will limit the maximum input message size to <y> bytes, as well (and will refuse based on the SMTP "SIZE" extension if present, or after the terminating "." for the "DATA" command, if not). > > II) Only root processes can override the reserve. This means pilot > > error in the most general sense. Pilot error can also write > > over the front of a raw disk; how does the software prevent > > one kind of pilot error, but not the other? It can't. > > 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. > > III) If you have a root process which is a daemon, good sense > > dictates that the process will have its own controls to > > prevent overriding the reserve. The syslog argument > > remains bogus, since you should use newsyslog instead, > > and avoid the issue. > > 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? You *must* be able to gracefuly fail on a resource failure; in other words, you must be able to handle any system call returning any error message which the system call may return based on the way you are using the call. > > For each example of badly behaved software you can come up with, I > > will either point to a well behaved piece of software, or I will > > simply say "then fix it". > > Please, let me use your magic wand on my software. I have no idea on > how applications might continue to work without impairment with full > filesystems. Seems to defy the laws of this uniserve. The *can't* continue to work; your wanting them to do so is what defies the laws of nature. What they *can* do (and *should* do) is fail gracefully. Do you think that any putative fix for the password file truncation bug can do anything *other* than fail gracefully? You expect it to allow the transaction on the theory it should grow more disk space to accommodate it? > > The FreeBSD penchant for destroying passwd files when the disk is full > > is an *error* in FreeBSD, and should be corrected. Then I can point > > at (I) above, and state "so what? So the disk is full...". > > Who said it destroyed the passwd file? It just attempts to build new > files, it it runs out of storage, it aborts, leaving the original passwd > file. It kinda leaves you in lurch though, because you can't make any > changes to it. So do three things: 1) Run as few things as possible as root; people bitch about the security implications all the time anyway. 2) Log in as root and delete things in excess of the reserve so you are no longer "in the lurch". 3) Up the reserve space to be back where it should be instead of the default FreeBSD picks to make owners of large disks happy; it was a bad political decision in the first place. Then you can be sure that you won't have to do #2 as frequently. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711192005.NAA19787>