Date: Thu, 3 Feb 2000 12:05:51 +1030 From: Greg Lehey <grog@lemis.com> To: Marcelo <bsdq@stgo.cl>, Alfred Perlstein <bright@wintelcom.net>, Technical Information <tech_info@threespace.com>, "f.johan.beisser" <jan@caustic.org>, Stephen <sdk@yuck.net> Cc: freebsd-questions@FreeBSD.ORG Subject: Partitioning disks (was: no subject) Message-ID: <20000203120551.N55303@freebie.lemis.com> In-Reply-To: <Pine.LNX.3.96.1000202134722.1214A-100000@stgo.cl> References: <20000202155352.A11038@visi.com> <4.2.2.20000202142914.06520bd0@mail.threespace.com> <Pine.BSF.4.21.0002021218320.289-100000@pogo.caustic.org> <Pine.LNX.3.96.1000202134722.1214A-100000@stgo.cl> <20000202095655.B26831@fw.wintelcom.net> <008701bf6dac$97b83ea0$020a0a0a@megared.net.mx> <4.2.2.20000202142914.06520bd0@mail.threespace.com> <Pine.LNX.3.96.1000202134722.1214A-100000@stgo.cl> <20000202095655.B26831@fw.wintelcom.net> <Pine.LNX.3.96.1000202134722.1214A-100000@stgo.cl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, 2 February 2000 at 13:47:42 +0000, Marcelo wrote:
>
> Hello,
> I have an 8 gig drive. 500m are swap since I have 256 in RAM.
> The rest is all mounted on /
> Is that bad?
> I was critized by a peer for not having split up the drive and mount
> individual partitions into /usr /var etc..
>
> But since the server will not be used by anyone (webserver and webmail) I
> am not concerned about users taking up space since they aren't any.
>
> But in general what is the rule of thumb on this? are there any speed
> advantages to having seperat partitions?
On Wednesday, 2 February 2000 at 14:36:09 -0500, Technical Information wrote:
> This is all very understandable from the SysAdmin's point of view.
Well, I don't know what you're talking about, since you don't quote
what you're referring to.
> But are there any comparable advantages for Joe Unix who is using
> his machine solo or with a few moderate users?
I don't know what you're comparing to. But I'd think the advantages
and disadvantages are the same for one or more users.
> And can't quotas be used to stop any rampant growth in particular
> areas?
Yes.
> I'm not doing backups or anything like that on my personal system,
You should be. You're going to lose something one day.
> and I never can predict which areas (e.g., var or tmp or usr) are
> going to grow the fastest.
This is my biggest objection to overly rampant partitioning.
> So I've also typically just installed everything into one large root
> [/] directory. For somebody without any experience or even a good
> idea of how a system may be used, directory subpartitioning seems
> like a hit-or-miss proposition at best.
Agreed. I think 99% of all people would fit into that category. I
had a long argument^Wdiscussion with a release engineer at a large
company recently. He wanted /var on a separate partition and that he
could accurately estimate the size. I said that he would run into
trouble. He did.
> Heck, I wouldn't even know how much room to allocate to the
> theoretically immutable root directory....
That's relatively easy. Take 50 MB.
On Wednesday, 2 February 2000 at 12:26:40 -0800, f.johan.beisser wrote:
> On Wed, 2 Feb 2000, Technical Information wrote:
>> This is all very understandable from the SysAdmin's point of view. But are
>> there any comparable advantages for Joe Unix who is using his machine solo
>> or with a few moderate users? And can't quotas be used to stop any rampant
>> growth in particular areas?
>
> yes and no. quotas is for limiting users. it's a bit to much overhead for
> the system as a whole, in my opinion. if you have rampant growth in any
> area, it's likely caused not by the users, but rather by the logs.
You want to limit the log files whether or not they're in a separate
partition.
>> I'm not doing backups or anything like that on my personal system, and I
>> never can predict which areas (e.g., var or tmp or usr) are going to grow
>> the fastest. So I've also typically just installed everything into one
>> large root [/] directory. For somebody without any experience or even a
>> good idea of how a system may be used, directory subpartitioning seems like
>> a hit-or-miss proposition at best.
>>
>> Heck, I wouldn't even know how much room to allocate to the theoretically
>> immutable root directory....
>
> generally, you can just guess. a best guess is usually better than the
> worst choice.
>
> my own machines are usually set with 100mb to the root partition, 50mb to
> /var and the rest over to /usr.
I would guess that your root partition is more than half empty, and
the /var partition is pretty full.
> this limits the users ability to affect the machine, or to accidentally
> break it.
You can break things by filling up /var. Mail will stop working, for
example, and some MUAs may end up trashing mailboxes if /var is full.
On Wednesday, 2 February 2000 at 15:53:52 -0600, Stephen wrote:
> On Wed, Feb 02, 2000 at 02:36:09PM -0500, Technical Information wrote:
>> This is all very understandable from the SysAdmin's point of view. But are
>> there any comparable advantages for Joe Unix who is using his machine solo
>> or with a few moderate users? And can't quotas be used to stop any rampant
>> growth in particular areas?
>>
>> I'm not doing backups or anything like that on my personal system, and I
>> never can predict which areas (e.g., var or tmp or usr) are going to grow
>> the fastest. So I've also typically just installed everything into one
>> large root [/] directory. For somebody without any experience or even a
>> good idea of how a system may be used, directory subpartitioning seems like
>> a hit-or-miss proposition at best.
>>
>> Heck, I wouldn't even know how much room to allocate to the theoretically
>> immutable root directory....
>>
>
> I've never run into problems with this strategy: Combine static partitions
> (/usr, /opt in solaris, ...) into root and give each dynamic partition
> (/var, /home, ...) its own. My own workstation goes something like:
>
> / 1GB
> /var 100MB
> swap 100MB
> /home freehog
This is a very unusual way to do it. You have /usr on the root file
system, right?
In summary, most people are saying:
1. Keep / small and separate, because that way you have fewer
problems if you crash.
2. Keep /var on a separate partition, because that way you limit
damage if your log files overflow.
Both of these approaches have their merits. I think (1) is OK,
because it's relatively easy to calculate the size of the root file
system, especially if /tmp is on MFS or a symlink to /var/tmp. (2) is
much more of a problem. People in this thread have between 50 and 100
MB for /var; a single big mail message could overflow a 50 MB /var and
cause mail to seize up. In fact, /var overflows are the biggest
single space problem I have seen administering a UNIX system, so
putting /var on its own smaller file system just makes matters worse.
In addition, these sizes are possibly not what you want. I have:
# du -xs / /var
26 /
1543 /var
Values are in MB. I won't claim that there isn't junk in /var, but
most of it is needed. The log files normally don't cause any
problems, but my /var/log hierarchy is 97 MB by itself. The squid
cache is 50 MB. /var/spool/ftp has 416 MB, including a complete
OpenBSD distribution. I have 540 MB of backup listings in
/var/backup. How do you decide in advance how much space you want?
I'm very much in favour of using quotas where necessary, especially if
they can be limited to a few directories, such as /var/log and
/var/tmp.
My rules of thumb are:
1. Keep / small and separate, because that way you have fewer
problems if you crash.
2. Make /tmp (and maybe /var/tmp) an MFS.
3. Make all other file systems small enough so you can back them up
on one tape.
Greg
--
When replying to this message, please copy the original recipients.
For more information, see http://www.lemis.com/questions.html
Finger grog@lemis.com for PGP public key
See complete headers for address and phone numbers
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000203120551.N55303>