Date: Wed, 19 Nov 1997 10:19:49 -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? Message-ID: <Pine.BSF.3.95q.971119101124.25964D-100000@misery.sdf.com> In-Reply-To: <199711191806.LAA12806@usr05.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Nov 1997, Terry Lambert wrote: > > > The log files are stored in /var/log. I always make /var a separate > > > partition. > > > > Yes, that is whole point. Separate comparments for everything is good. > > Terry seems to believe otherwise. > > Wrong. I gave ten good reasons why you would want things seperate, > whereas the original poster gave one bad one. > > You can't argue "filling the disk up". It's a bogus argument: > > 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. > 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. > 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. > 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 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 only file in my root partition that has been modified in the last > > > week is /etc/dumpdates. > > > > And that might be a debatable location for that file. It is nice have / > > as static as possible. Some other things: /etc/aliases, > > /etc/master.passwd > > I definitely agree with this. / should be read-only. So should /usr, > if you want to get down to it. /usr is considerable easier to make ro than /. /etc/ is abused. > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > > Tom
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.971119101124.25964D-100000>