I don't think it's possible to state a set of canonical rules. I do it differently
on different systems, depending on the intended use and the hw config.
That said, I think it's possible to set out some basic principles and guidelines.
Here are some of my personal considerations:
Ignoring the low-level compulsion to overcome braindead hardware limitations,
there are two high-level reasons to split the file space into partitions: having
separate file system structures and using different spindles (drive units). That's
assuming a single-boot system, my work laptop is set up to boot Win98,
Win2K and RedHat (with unused partitions reserved for Solaris and FreeBSD,
if I ever get around to loading them), so my partition structure there was
constrained by factors outside of Linux.
Anyway, strictly within a single system environment, splitting the files across
spindles has some advantages, if you have multiple drives. It sounds like
this is something you're already familiar with, but it merits consideration.
I like putting /usr and maybe other application or user files out on another
drive, for several reasons that I won't go into (unless somebody asks and
nobody else answers :-).
As far as I understand it, the biggest reason for having separate file systems
is prevent the intentional or inadvertent denial of service that results from
filling the disk. OTOH, splitting the disk up into a bunch of small chunks
may mean that one of them gets full sooner than if it could grab from all
the available blocks (I proved that last week!). There might be some
performance advantages also from having separate partitions, I'm not
as familiar with all that. My prime concern on both those counts is
/var/log, but I'll consider it on others as well.
There's also some potential for some crude mirroring or online backup.
The mention of a spare / is one, if you're disk rich you could even do
that with /usr or other trees. Personally, I haven't yet gotten around to
it, but making a spare / or /boot on the other drive would be a good
safety net.
Last thought, I've read several different authors' recommendations
and they overlap somewhat. I'd recommend looking at a few different
ideas, trying to understand the underlying rationale, and then designing
something you think is appropriate for your needs. Isn't that the
whole idea of open source anyway?
Just MHO.
--Bruce McCulley
Dan Jenkins wrote:
> Tom Rauschenbach wrote:
> > I just bought a 10 gig drive (the smallest available) to replace a failing
> > drive. The drive that is failing is of course the drive I boot from and that
> > has /, /root, /usr, /etc, /opt, /tmp, /var, /usr/local, and /usr/src all as
> > separate file systems. Basically it's where all my system software lives.
> > User data is on different spindles or different partitions on that drive. So
> > now I have an opportunity to reorganize my system software partitions.
> >
> > So I suggest that we discuss
> > 1) which directories should be separate file systems
> > 2) how big should they be
> > 3) other stuff related to disk organization
>
> Everyone has an opinion. It's like asking the best way to organize your
> closet and drawers. I do it differently depending on the application of
> the system. As distros are pretty stable now, for most desktop systems,
> I'd probably keep a 256 MB or larger / (with /tmp, /root, /etc & /var in
> it), a separate /usr of 2 GB or more (with /usr/src in it) (and a
> symlink from /opt to /usr/opt - which I doubt is FSSTND) and a
> /usr/local of whatever size you need.
>
> I can't see any significant benefit, but some disadvantages, to having
> /etc, /tmp & /root separate from /. I like to keep /var separate if
> there's a lot of activity there - logs, email, etc. - again, for desktop
> use, I keep it in /.
>
> I would keep a redundant / which lilo can boot from. It's saved me a few
> times. At least it gives a checkpoint to diff against to see what's
> changed since / last worked. ;-)
>
> Enough of my opinions, let's hear others...
> --
> Dan Jenkins, Rastech Inc., Bedford, NH --- 603-627-0443
> *** Tech Support for over Twenty Years
>
> **********************************************************
> To unsubscribe from this list, send mail to
> [EMAIL PROTECTED] with the following text in the
> *body* (*not* the subject line) of the letter:
> unsubscribe gnhlug
> **********************************************************
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
