Mailinglist Archive: opensuse (4343 mails)

< Previous Next >
Re: [SLE] partition magic can it and advice?
  • From: Tom Emerson <osnut@xxxxxxxxxxx>
  • Date: Fri, 22 Nov 2002 02:24:31 -0800
  • Message-id: <200211220224.31563.osnut@xxxxxxxxxxx>
On Thursday 21 November 2002 18:10, Rick Reumann wrote:
> On Thu, 21 Nov 2002 17:59:38 -0800
> Tom Emerson <osnut@xxxxxxxxxxx> wrote:
> > [see also my response on naming partitions, though perhaps a better
> > thread topic for both of these is "partition types, sizes, and uses"
> > :) ]
> When you get back from your meeting Tom maybe you'll get this:) Saw that
> other post and I was lost:)

I see you've added a smiley, so you got my point -- there are a TON of ways of
setting up partitions and filesystems for linux (but "fat" is rarely one of
them :) )

I've also read the rest of the posts on this, and I see the inevitable
question came up: what sizes should I make these? and the inevitable
answer(s), starting with: "Then various Linux people have varying ideas as to
how it should be split up from there." [Howard Coles] to which I'll throw my
two cents into the ring:

/boot: this does not HAVE to be very large, BUT with HD sizes increasing
daily, "the smallest" you can make it is "one [logical] track", and often
"one track" is 20-30MB! There are various reasons for having a separate
/boot partition, the most notable having to do with BIOS [begin history
lesson] older "boot" code only accessed the system via the BIOS, and BIOS
level disk-read calls are limited to 1024 tracks -- modern boot loaders (like
linux itself) do not rely entirely on the BIOS, so they can "read" the entire
disk. [end history lesson]

So, as one person pointed out, with "modern" boot loaders (and/or BIOS's)
there is little need for a separate (small) boot partition in the first 1024
tracks, however I'll point out a case where a "small" partition does have
it's advantages: if you're running "raid" or "LVM" for your root partition
(as I am on one system) you'll probably find it easier to manage if /boot is
not part of the "raid" or LVM partitions.

The <swap> partition: as noted, this depends entirely upon what you intend to
do with your system -- "general workstation work" using KDE, "openoffice",
and the like, probably doesn't need much "swap" space (if any) as most
"home/small office" systems have relatively HUGE amounts of live ram, and
with an (essentially) single-tasking user at the keyboard, very little
"swapping" goes on. "specialized" work, such as audio or video editing, will
benefit from larger "swap" sizes [as well as more physical memory, which is
actually different than windows 98 -- adding "too much" memory to a win98
system actually slows it down!] Systems truly being used as "servers" with
multiple processes competing for resources will benefit from larger swap
partitions as well.

/home: again, this depends on "what you do" with your system. multi-media
fanatics will benefit from larger partitions. This includes "Download
junkies", e-mail rat-packers, and mp3/avi addicts. <hi, my name is tom, and
I'm a download junkie...> [everyone, in unison] "Hi, tom!"

seriously, though, as disk prices continue to fall through the floor and
"media bloat" continues to rise, bumping this higher than you expect you'll
ever need probably won't hurt...

/opt and/or /usr/local: (note that mounted partitions don't have to be "at the
root level", so it is entirely possible to have "/usr/local" be a separate
partition while "/usr" itself remains part of "/") Basically, the purpose of
these directories is to house add-on applications that are not part of the
"core" operating system. Because these are not specifically related to the
OS itself, the case can be made to keep this partition "intact" during an
upgrade (like /home), and with a little luck, you can re-install or upgrade
the core system without having to re-install the (add-on) applications [the
reality of this, however, is that most likely you'll want to install
distribution-level-specific versions of the add-on applications anyway, so
perhaps this is a moot point...]

/var and /tmp: again, your (users's) usage patterns will determine how large
these partitions need to be (that is, if you are separating them from "/" in
the first place) "it used to be" that filling your "root" partition was a
bad thing -- if you've ever done this in windows, you'll know what I'm
talking about -- Unix was even more notorious for "having problems" if the
root filesystem became "full". HOWEVER, I'm here to tell you I've taken my
"root" filesystem down to 24k free (or less) and lived to tell about it [and
my "root" filesystem is 16GB!] Turns out I had done something "boneheaded"
and started some process that was logging information to "stderr" --
unfortunately, "stderr" in a graphically-based login happens to be the file
/var/log/Xfree86.0.log -- eventually it consumed every bit of free space in
"/" since I had set this system up as a single partition (including /home AND
/root) because I wasn't expecting to do much with it. Even though I was
getting strange errors (unable to create files), the system still continued
to "operate". When I figured out what was happening, it was a simple matter
to switch to runlevel 3 [killing the "X" process], purge the file, and
returning to runlevel 5 [restarting X with a new log file]

/root: not talked about much, but the above "problem" [filling the HD] is the
reason you'll sometimes hear advice on making /root a separate partition
(/root is not to be confused with just "/", which when spoken is often
referred to as "root") Basically, this is the "home directory" of the "root"
user -- by placing it into a physically separate partition, "rogue programs"
like the one I started may cause the system to grind to a standstill by
filling "/", but you'll still be able to log on as "root" and "do stuff"
because you'll have free space in "root"'s home directory.

"chrooted" partitions: (a.k.a. "jails") If you plan on isolating a "service"
(such as ftp, dns, or your web server) from the "system", you'll be placing
the data or work files for said service in what is called a "chroot jail".
In a nutshell, "chroot" means "change the root location for a process". From
the process's point of view, whatever directory you change this to (by
definition, "lower" on the directory tree) is the root directory, or "/".
Once changed, it cannot change to anything "higher" [closer to the real
"root"] because it cannot "see" anything higher than "/". Physically
isolating "chrooted" processes to another partition (or drive!) helps limit
any "damage" an intentionally malicious user of the "service" might attempt
to commit.

/ and everything else: by now you've probably realized that I've avoided "hard
actual numbers" for partition sizes -- that was intentional -- but when
you're done with the above, most everything else will be "part of the root
filesystem", so allocate that last (mentally, not physically -- you'll
probably want to "physically" allocate "/" early on in the process so that it
resides in a particular location of the disk(s)

Also, while I've enumerated the reasons for breaking out certain partitions,
I'm going to throw it all out the window and claim "using the Microsoft
mentality of throwing everything onto C: may be better (for now)". The
single overriding factor behind this is "you are new to linux" -- most of my
suggestions are along the lines of "your usage patterns will determine the
size needed", but until you've actually used the system, you won't know your
"usage patterns"! [the ones that aren't are advanced topics anyway --
chroot, for instance...]

There is also another topic which I've only alluded to: "LVM", or "logical
volume manager" -- this lets you combine multiple physical drives and
partitions into a single or "logical" partition. [for win3.1 there was a
product called "one big disk" or something like that which does the same
thing; also "promise" makes an IDE controller called "fast trak" which can
combine physically different disks into "one big disk"] You can also
dynamically shrink or grow (logical) partition sizes by removing or adding
physical partitions via the LVM, so if you run out of space, you can add
another drive and "grow" the partition. Note however this is a very advanced
topic [meaning I haven't done enough with it yet to feel comfortable
"teaching" it to someone else...]

> All I know is on this windows98 machine it
> was easy with Suse I put disk 1 in and followed some prompts and I was
> done.

I don't see that this has to be any different for XP, especially if all you do
is "shrink" the area taken by XP and [start with] SuSE's "suggestion" on how
to partition the rest. [as someone else noted here, "you are an expert,
right?" I hope that by the time you've read what I have written here, you'll
understand enough to take the "expert" path without fear of a misstep :) ]

< Previous Next >
Follow Ups