Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Jan 2002 15:46:07 +0100
From:      Brad Knowles <brad.knowles@skynet.be>
To:        "Mike Meyer" <mwm-dated-1012390758.50933b@mired.org>, Brad Knowles <brad.knowles@skynet.be>
Cc:        chip <chip@wiegand.org>, freebsd-chat@freebsd.org
Subject:   Re: Bad disk partitioning policies (was: "Re: FreeBSD Intaller   (was  "Re: ... RedHat ...")")
Message-ID:  <p05101245b8771d04e19b@[10.0.1.3]>
In-Reply-To: <15441.17382.77737.291074@guru.mired.org>
References:  <20020123114658.A514@lpt.ens.fr> <20020123124025.A60889@HAL9000.wox.org> <3C4F5BEE.294FDCF5@mindspring.com>	<20020123223104.SM01952@there> <p0510122eb875d9456cf4@[10.0.1.3]> <15440.35155.637495.417404@guru.mired.org> <p0510123fb876493753e0@[10.0.1.3]> <15440.53202.747536.126815@guru.mired.org> <p05101242b876db6cd5d7@[10.0.1.3]> <15441.17382.77737.291074@guru.mired.org>

next in thread | previous in thread | raw e-mail | index | archive | help
At 5:39 AM -0600 2002/01/25, Mike Meyer wrote:

>  That's a different issue from keeping /var, /usr and / separate. I
>  actually do that by linking /var/tmp to /tmp, and mounting /tmp. That
>  solves all the problems of what to do about /tmp if it's symlinked to
>  /usr/tmp (which doesn't exist on my systems).

	That's another way to solve the problem, if you're willing to 
intermingle /var/tmp and /tmp.  I prefer to keep them separate, with 
the option of making /tmp a small mfs, so that it's wicked-fast in 
addition to everything else.

>  It seems like all those extra partitions aren't providing any extra
>  protection - at least for the server I've got here.

	Indeed, my methods may not help you much with the system you 
have.  It all depends on what is happening on the machine and how the 
various filesystems are being used.  For machines that log a whole 
lot of data (mail systems with logging turned up to high levels for 
accounting or accountability reasons, web servers, etc...), I believe 
that things like this may be more important.

>                                                       On the other hand,
>  as the various things in that slowly creep up in size, I won't have to
>  deal with it until the total space allocated is gone, whereas you'll
>  have to deal with it as soon as any one of them runs out of space.

	I usually install log file management tools that centralize 
all the log data from various machines onto a separate server, and 
very little (if any) log data is ever kept locally.

	I used to use syslog for this, until we discovered that we 
were losing something like 75% of all data being sent to syslog 
(since it's based on a UDP protocol), and yet still getting multiple 
gigabytes of log data that were produced on a daily basis.  If syslog 
is used, I now prefer to syslog locally and then use other methods to 
periodically rotate the log file and move the old ones to a separate 
machine.

>  In my experience, that's true of workstations, but not servers. Then
>  again, I make sure that data files that need to change on servers are
>  configured to be outside of /usr/local, just to avoid that problem.

	I've seen this on the servers that I administered at AOL (as 
the Senior Internet Mail Systems Administrator, I was responsible for 
creating schemes that would work across all our hundred-plus 
servers), and I've seen this on pretty much every server I've ever 
installed or administered since then.  Indeed, I've seen this kind of 
behaviour throughout the twelve-plus years that I've been doing Unix 
systems administration.

	The basic stuff in /usr doesn't change too much, but if 
you're keeping up with updates to packages that are under constant 
development, or if you're keeping up with the latest security holes & 
patches, I simply don't see any alternative -- if it's not in 
/usr/local, then it's someplace else and poses an equal problem/risk.

>  So what does this have to do with the case where you've blown 10s of
>  GB vs. / and /var being on different file systems?

	Well, since user-level programs can't write into the reserved 
disk space allocation (used to be ~10%, but I don't think that this 
really makes much sense with modern 100GB+ high-capacity disks, 
etc...), it doesn't completely and totally blow you out of disk space 
if they fill up what space they are allowed to write in.

	Since /var/log is a separate filesystem, having it fill up 
doesn't affect any programs that depend on use of /var/tmp (like vi, 
or any other system program that might need to create temporary files 
during operation).

	I also separate off the major applications into their own 
filesystems, too.  So, the /var/spool/mail and /var/spool/mqueue on 
mail servers are separate filesystems (even separate from each other, 
so that mailboxes overflowing on /var/spool/mail doesn't prevent you 
from accepting and routing mail through /var/spool/mqueue and 
vice-versa), web servers get their own separate filesystem, etc....

-- 
Brad Knowles, <brad.knowles@skynet.be>

H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-chat" in the body of the message




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