Date: Mon, 24 Nov 1997 21:13:34 -0800 (PST) From: Simon Shapiro <shimon@simon-shapiro.org> To: Tom <tom@sdf.com> Cc: hackers@FreeBSD.ORG, craig@ProGroup.COM, Don.Lewis@tsc.tdk.com, Terry Lambert <tlambert@primenet.com> Subject: Re: Partitioning suggestions? Message-ID: <XFMail.971124211334.shimon@Simon-Shapiro.ORG> In-Reply-To: <Pine.BSF.3.95q.971119101124.25964D-100000@misery.sdf.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19-Nov-97 Tom 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. Only if a million dollars check got lost. A descent MTA should not dump mail on the floor if the disk is full. Thsi is what stat(2) is for. A catastrophic failure is one that damages the system and stops it from working; like Slowlaris when the filesystem is full (write into the next slixe and destroy that too.). Actually, if you look at an MTA as a database application (one which stores and retrievs data, based on client requests), you get the willies looking at most MTA programs and their disregard to safety and sanity. This is not an O/S problem. disk Partitioning? The more the marrier. > >> 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. If a process (not a human) routinely and automatically overrides the reserve, then there is, by definition, no reserve. It is like the speed limit; Makes the politicians feel like they are actually contributing to society. >> 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. A ten line change can fix that. Check for free space before you write. You do look both ways before you cross a busy street. Right? Tery is right. These are bugs which are trivial to fix. >> 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 application may be impaired. But should not crash. the system should not be impaired. MTA can defer messages, word processors can refuse to save. vipw can refuse to write over good files, etc. RDBMS (true ones) do NOT use the filesystem for this exact reason. >> 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. The rm(1) command still works. So does mv(1). It is acceptable for a system which is running into resource bind to stop accepting new transactions, so long it tells you why it stops receiving. What you describe is perfectly correct behavior. Even the best latex has limits on stretching - This is why we abandoned using it for disk media :-). Besides, most disk manufacturers still use metal for platters - does not stretch worth a darn :-) If Microsoft Built Cars: There would be an "Engine Pro" with bigger turbos, but it would be slower on most existing roads. Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.971124211334.shimon>