Re: Corel/Debian Linux Installer
On Mon, Aug 16, 1999 at 10:49:32AM -0600, Jason Gunthorpe wrote:
> On Mon, 16 Aug 1999, Christopher W. Curtis wrote:
> > I mist first say that I have not seen the installer; I've seen some
> > screen shots but all that is eye candy is not all which is useful.
> > The most confusing thing for many people is how to partition
> > the hard drive. Red Hat and Caldera take the approach that a
> > bad partitioning is better than none, and tend to create a swap
> > partition and then a single huge partition for data. Or two. This
> > is foolishness.
>
> No, it isn't. There isn't a single good reason to partition a disk
> into little chunks on a end-user workstation - and these days there
> are some valid but generally not very important reasons to do it on a
> server.
>
> The two most compelling reasons to carve a single drive into little
> partitions are space management and mounting /usr readonly. On a
> single user workstation neigther are very important, and for alot of
> servers they are not important either.
>
> It used to be a good idea to partition like this because drives were
> small and unreliable, so you bought a /usr, /var, /home DRIVE simply
> to have enough space.
very true. these days with *minimum* disk sizes of 3 or 4 gig, it's not
worth the bother of making lots of little partitions...once you've
decided that / is going to be small then you have no choice but to make
separate partitions for /usr, /var, /home, and probably /tmp.
i generally don't mount / or /usr as read-only so there's little or
no point in putting them on separate partitions - they're going to be
fsck-ed after a crash anyway.
i find that creating arbitrarily small partitions actually causes
hassles anyway - it's bloody irritating to have gigabytes free in /var
or /home but be unable to install anything because /usr is nearly full.
apart from making an ugly mess of symlinks, the only way to get around
that is to backup everything, repartition, reinstall, and then restore.
my rules of thumb:
- a small 30MB partition for /boot where kernel images live. not really
needed these days but is a habit from the old days where kernels had
to be located under cylinder 1024.
- every machine has one or more 128MB swap partitions
- however it is partitioned, the /usr directory should have at least a
gig, preferably two.
- /var directory needs lots of disk space, especially on servers which
do a lot of logging. minimum 250MB. preferably 500MB or 1GB. unless
you have lots of disk space on / it is a good idea for /var to be a
separate partition so that you don't risk filling up /
- dedicated-task servers get separate drive(s) for their main data disk
(e.g. a mail server gets a whole drive dedicated to /var/spool/mail)
- on a workstation, /home gets a few gig...whatever is left over after
/usr and /var are catered for. on a server /home is irrelevant.
e.g. for a proxy server with IDE boot disk and scsi data disks, i would
partition it like so:
/dev/hda1 swap 128MB
/dev/hda2 swap 128MB
/dev/hda3 /boot 30MB
/dev/hda4 / remainder of disk...i.e. 3 or 4GB.
/dev/sda1 /cache1 (entire disk)
/dev/sdb1 /cache2 (entire disk)
/dev/sdc1 /cache3 (entire disk)
i vary this from machine to machine, depending on exact
circumstances...but the above works fine.
alternatively, instead of a 3 or 4GB /dev/hda4 / partition, i
might have 2GB /dev/hda5 / partition and 1 or 2GB /dev/hda6 /var
partition...depending on how worried i was by the possibility of log
files filling up /
a mail server would be very similar, except that the scsi drives would
be a combined raid disk (either hardware raid or linux software raid)
mounted as /var/spool/mail. a mail server would probably also have a
separate /home partition (possibly a separate drive).
a web server would also be similar, but would have the scsi disks as a
raid array for /var/www and would definitely have a separate drive for
/home (for the ~/public_html directories)
a database server would again be similar, but would have the scsi disks
as a raid array for /var/postgres.
in summary: disk is cheap and plentiful these days. worrying too much
about partitioning is counter-productive.
craig
--
craig sanders
Reply to: