Why partition a perfectly good disk?
RJG
the disk as boot, usr, var, and home. Why?
If the host BIOS won't recognize the full size of the disk, the boot
partition is required for the kernel, but spreading the other
directories across multiple partitions on the same drive just forces
the drive to thrash more while eliminating any automatic optimizations
that are built into the file system. Plus, it eliminates total
flexibility by requiring that you decide ahead of time how much space
to give each partition.
The only advantage to this scheme that I can see is it eliminates the
possibility of users filling up the system partition and stalling the
system, but there are better ways to accomplish this.
Somebody, please explain the rational for this (as I see it) stupid
partitioning scheme.
Thanks!
Lurch
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
Security reasons:
mount the /usr and the /boot partition read-only (instead of read-write)
Avoid that logging or malicious programs will fill up the entire disk:
/tmp and /var are put on a different partition
there are probably many other reasons...
Dave Blake
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
boot - just the kernel and boot images.
usr - the install disks - just system software and libs
var - stuff that resides for variable periods of time, but
shouldn't be permanent
home - users own stuff - permanent.
For one thing, backup strategies. You want good regular backups
of home partitions. You only need to backup usr after
reinstalling software. You might not want to back up /var at
all. Or /tmp.
Another benefit to this is that it makes it very tough for a
power loss to destroy the file system. Only filesystems being
written at the time of loss are particularly vulnerable, and if
usr and boot are isolated, the machine should reboot just fine.
Try losing the /bin inode due to filesystem corruption sometime.
On a standalone box that is not heavily used I make minimal
partitions. One for swap, one for everything else.
--
Dave Blake
dbl...@phy.ucsf.edu
Michael Lee Yohe
> mount the /usr and the /boot partition read-only (instead of read-write)
>
> Avoid that logging or malicious programs will fill up the entire disk:
> /tmp and /var are put on a different partition
>
> there are probably many other reasons...
Flexibility of file systems.
I.e., on a test development system of mine, I have reiserfs handling a partition with very small files. I have ext3 doing the bulk of the work otherwise.
Low fsck times.
No matter if you use a journaling file system (most people don't), you
will probably have to perform a fsck sometime on a critical partition.
Smaller = faster.
--
Michael Lee Yohe (myohe+...@redhat.com)
Software Developer, Engineering Services
Red Hat, Inc.
QUIPd 0.12:
-> I always find it quaint that people who rant and rave
-> against the silliness of self-reference are themselves
-> composed of trillions and trillions of tiny
-> self-referential molecules.
-> - Douglas R. Hofstadter
Robert Heller
In a message on Thu, 20 Sep 2001 16:51:32 -0400, wrote :
R> I have noticed that many dedicated server hosting providers partition
R> the disk as boot, usr, var, and home. Why?
R>
R> If the host BIOS won't recognize the full size of the disk, the boot
R> partition is required for the kernel, but spreading the other
R> directories across multiple partitions on the same drive just forces
R> the drive to thrash more while eliminating any automatic optimizations
R> that are built into the file system. Plus, it eliminates total
R> flexibility by requiring that you decide ahead of time how much space
R> to give each partition.
R>
R> The only advantage to this scheme that I can see is it eliminates the
R> possibility of users filling up the system partition and stalling the
R> system, but there are better ways to accomplish this.
Yes and no (disk quotas anyone?).
R>
R> Somebody, please explain the rational for this (as I see it) stupid
R> partitioning scheme.
R>
R> Thanks!
R>
A *big* part of the "many partitions" scheme relates to isues of file system
stability, file system sharing, file system security, and general
reliabity issues. It also in part relates to multiple O/S issues and
backup issues.
Under UNIX in general, certain 'file systems' have distint behavioural
features:
/boot and /usr -- extremly *static*
/etc -- mostly *static*
/var -- highly *volitle*
/home -- moderatly *volitle*
/var/spool/news -- *extremly* *volitle*
etc.
What this means is this: A fairly small (on the order of 100 meg) root
file system (which generally contains all of the *esentual* stuff needed
for Linux to be reasonably 'up'), will almost never fail a fsck, unless
the disk has totally farmed. This means ones system has a higher
relibabity -- it is less likely that a *minor* problem with the disk
with totally kill your system (everything lost).
Having a separate /var fs (and/or a separate file system for /var/log
or /var/spool/* etc.) keeps its high fragmentation issues from messing
anybody else up -- between /var/spool/* (mail, lpd, news, etc.) and
/var/log/*, /var gets beat on. On a machine that is NOT up 24/7,
/var/log can become 'full' this can cause interesting 'failure' modes
for many users -- X11 will fail to start properly if there is no free
disk space -- not fatal to *Linux*, but for a box with a default
runlevel of 5, the system will appear to be 'crashed' to the novice
user. Also if the fs where /var is fills up, lpd will *seem* to stop
working. Again not truly fatal, but things will appear 'broken' to a
novice user. So, by having /tmp, /usr/tmp, and /var/spool/lpd on a
different file system from /var/log, keeps things 'working' enough to
give the novice user a system that is working.
/home (and any other random user data areas) will generally be
problematical. Yes, disk quotas can prevent *users* from totally
filling the disk, but how much slack space should one leave for the
system? And if you have multiple users, how do you assign space so that
every *user* has as much space as they need, but that no one user or any
random set of users does not fill up the disk? I know, UNIX reserves
10% of the disk for the system, but the system itself (daemons) an fill
up the disk too. It is generally *simplier* and far less hassle to put
/home on its only partition. This means that no matter what the users
do to it, the *system* won't ever be affected.
If one uses *any* sort of networked file sharing, there are lots of
random security issues -- one does not want to randomly export *system*
directories to foreign system, where security is an unknown issue.
Samba, NFS, and NetATalk/CAP don't exactly do a chroot, which does not
really have much effect on hard links anyway. Having the system
directories on *different* file systems is a reasonable security
precaution. OTOH, a (trusted) cluster of Linux systems might want to
share /usr and /var/spool/mail, and /home, but not /etc. This allows a
uniform system with really simple O/S upgrade issues (update the server
box and all systems are upgraded).
Then there is backup:
Because the base system directories (/boot, /bin /sbin /lib /usr/*) are
esentually *static*, there is little need to frequently back these
directories (or even to back them up at all). The only *system*
directories that are all 'volitle' are /etc (config stuff) and /var
(logs and additional config stuff). A printout of one's config (i.e. IP
numbers, etc.) and an occasonal backup copy of /etc/passwd, /etc/shadow,
and /etc/group is generally enough -- these are all *small* files -- can
be stashed on a floppy -- maybe even the files under /etc/sysconfig as
well. Most of the stuff under /var/log is expendable (nice to have, not
something you need bother to restore if the hard drive farms). You can
save a lot of backup media by not backing up stuff you don't really need
to. (Note: /usr/local might be a special case under /usr or might not
be, depending on if you keep backup copies of the .tar.gz, etc. files
used to populate /usr/local/.)
By putting 'static' system file systems on their own partitions, your
backup issues are simplified -- the most common backup utility, dump,
dumps by *file system*, not directory, and other backup options can also
be limited to 'one file system' to limit their backup activity.
Also, some people might want to have multiple O/Ss (including multiple
versions or distros of Linux). Some O/S can 'share' file systems --
multiple Linuxes can share a /home and a /var/spool/mail and possible
/boot file systems, but not / or /usr or /var/log or /var/rpm, etc.
Note: not all of these issues apply to all users or installs. Some do
and some don't and different users may have things to consider. I am
just listing ALL of the issues and all of the reasons for the multiple
partitioning.
--
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
Joshua Baker-LePain
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
In addition to the other uses mentioned, ease of upgrade. Splitting off
/home allows you to blow away the system without blowing away user data.
I usually give /usr/local it's own partition as well, so that I don't
have to blow away custom installed software when I upgrade.
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
Bob Hauck
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
For reliability, security, and ease of doing upgrades. You can mount
/boot and /usr read-only to reduce the risk of a power failure or other
hard stop making your computer unbootable. It also has a minor
security benefit. I often put /var and /home on separate partitions
so that users and log files can't fill up the root drive and so I can
have quotas on /home.
Also, on large servers with scsi drives, there is a performance benefit
to having not only separate parititions for things, but separate drives
as well. Lots of smaller drives are usually faster than one big one,
especially with scsi being able to overlap commands to the drives.
For workstations, my normal scheme is to make /usr/local and /home
separate partitions merely in order to make OS upgrades easier. I can
upgrade by just backing up /etc and reinstalling.
> The only advantage to this scheme that I can see is it eliminates the
> possibility of users filling up the system partition and stalling the
> system, but there are better ways to accomplish this.
Quotas are per filesystem, not per directory (well, at least in 2.2 and
earlier kernels they were).
--
-| Bob Hauck
-| To Whom You Are Speaking
-| http://www.haucks.org/
Måns Rullgård
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
>
> If the host BIOS won't recognize the full size of the disk, the boot
> partition is required for the kernel, but spreading the other
> directories across multiple partitions on the same drive just forces
> the drive to thrash more while eliminating any automatic optimizations
> that are built into the file system. Plus, it eliminates total
> flexibility by requiring that you decide ahead of time how much space
> to give each partition.
Look at LVM. http://www.sistina.com
--
Måns Rullgård
e99...@e.kth.se
Joal Heagney
As others have pointed out, the main reasons are:
1) Security. Good to have /usr and most of / locked off as read-only
(Not that I usually bother on home systems.)
2) Safety of data. I especially like to have /boot and /lib locked off
as their own partitions. It can be a bit of a squeeze when I try to
upgrade the kernels, but I have had some massive disasters on my
machine. Before I started keeping /boot seperate, such disasters if it
involved root (Don't ask) made my entire system unloadable. Now they're
just merely increadibly difficult.
3) Ease of upgrade.
I recently converted to Reiser-fs (sweeeeat), but I had masses of data
sitting on /home. While I backed up the really important data, the rest
of it was pics and configuration files, convenient but not necessary.
So I did an upgrade as a fresh install, not touching /home, but making
another partition the same size as it. I copied over the data to my new
directory, re-configured my mount tables and everything, reformatted my
old home partition as reiser-fs, copied the data back, then did a fresh
install, wiping out the temporary partition so I could regain some /var
space.
If I had kept everything as a single partition, then I would have either
had to back up everything, or sacrifice some data and configuration
files. It's one of the best practices that fellow linuxers ever got me
into. The big hassle is knowing how much space to leave for each
partition.
--
Joal Heagney is: _____ _____
/\ _ __ __ _ | | _ ___ |
/__\|\ || ||__ |\ || |___|/_\|___] |
/ \ \_||__ ||___| \_|! | | \ \ !
Bill Unruh
]I have noticed that many dedicated server hosting providers partition
]the disk as boot, usr, var, and home. Why?
]If the host BIOS won't recognize the full size of the disk, the boot
]partition is required for the kernel, but spreading the other
]directories across multiple partitions on the same drive just forces
]the drive to thrash more while eliminating any automatic optimizations
]that are built into the file system. Plus, it eliminates total
]flexibility by requiring that you decide ahead of time how much space
]to give each partition.
Yes, it has disadvantages. And it has advantages. When you try to reinstall the
system, ( eg going from Redhat 6 to Mandrake 8) it is nice not to have to
wipe all the home directory to do so. You just wipe the / and /usr partitons.
(or / if you put /usr on / and not on a speparate partion) In /usr/local is also on a d
different partition you do not have to reinstall all those programs you installed from
tar files. Ie, th emain reason is for backup and restoring stuff. And you WILL have to do that
]The only advantage to this scheme that I can see is it eliminates the
Joal Heagney
>
> Ie, th emain reason is for backup and restoring stuff. And you WILL have to do that
Quite frequently. :)
James Hedgespeth
don't do this as much as I used to. When I limited disk space in
partitions in the past, I found that it was a real pain when I upgraded
the operating system and ran out of disk space in the partition. It's a
real pain in resizing partitions when you are short of space in one
partition and have a lot of space in another. Also, when installing Red
Hat software using RPM's, you don't have much control over where the
applications are being installed to.
Jim
Kasper Dupont
Most software installed from RPM's goes into /usr. A way
to use this is to make a large partition for /usr and
small partitions for / and /home. You probably don't
want to backup /usr but a backup of the others will be
nice.
--
Kasper Dupont
Floyd Davidson
Symbolic links were invented to make that easy and painless.
There is no need to resize partitions, just use symlinks to
allow directories on other partitions to be found where they are
expected to be.
E.g., if /var is running out of space, mount a 10Gb partition as
/u1 and move /var/X11R6 to /u1/X11R6 and symlink it back to
/var/X11R6. Do the same with whatever is necessary to clear
space in that or any other partition.
--
Floyd L. Davidson <http://www.ptialaska.net/~floyd>
Ukpeagvik (Barrow, Alaska) fl...@barrow.com
Eric P. McCoy
> James Hedgespeth <jhed...@accmail.umd.edu> wrote:
> >There are lots of good reasons for doing this. There is one reason why I
> >don't do this as much as I used to. When I limited disk space in
> >partitions in the past, I found that it was a real pain when I upgraded
> >the operating system and ran out of disk space in the partition. It's a
> >real pain in resizing partitions when you are short of space in one
> >partition and have a lot of space in another. Also, when installing Red
> >Hat software using RPM's, you don't have much control over where the
> >applications are being installed to.
> Symbolic links were invented to make that easy and painless.
They also add a level of indirection which can, under some
circumstances, turn your file system into a nightmare. And,
naturally, it complicates "don't move off the filesystem" backups.
> There is no need to resize partitions, just use symlinks to
> allow directories on other partitions to be found where they are
> expected to be.
LVM would also be a good solution. It is _so_ nice just to do:
# lvextend /dev/system/var -L +500M
# resize_reiserfs /dev/system/var
and have 500MB more available.
An attempted upgrade to 2.4.9 caused serious problems for me, so I'd
probably recommend staying away until the 1.0 LVM code makes its way
completely into the official kernel... but still a very nice deal.
> E.g., if /var is running out of space, mount a 10Gb partition as
> /u1 and move /var/X11R6 to /u1/X11R6 and symlink it back to
> /var/X11R6. Do the same with whatever is necessary to clear
> space in that or any other partition.
I like my solution better. Obviously you should still try to minimize
the number of extensions or you get fragmented logical volumes, but so
far a policy of expanding in powers of two has been pretty successful
for me.
--
Eric McCoy <ctr2...@yahoo.com>
"I woke up this morning and realized what the game needed: pirates,
pimps, and gay furries." - Rich "Lowtax" Kyanka
Garglemonster
James> system and ran out of disk space in the partition. It's a
James> real pain in resizing partitions when you are short of
James> space in one partition and have a lot of space in
James> another. Also, when installing Red Hat software using
James> RPM's, you don't have much control over where the
James> applications are being installed to.
so don't use rpms. tarballs will do fine, even on redhat systems.
i don't suppose many will agree with me, but i think rpms are more
trouble than they're worth. never missed them once i moved from to
slackware.
g.m.
I invented skydiving in 1989!
Eric P. McCoy
> so don't use rpms.
I don't.
> tarballs will do fine, even on redhat systems.
Sure, but then you can't do things like:
# apt-get update; apt-get upgrade
...which will upgrade the easily-upgraded packages on your system
automatically. For various reasons this may not be a good thing in
your situation, but for me it's very convenient.
> i don't suppose many will agree with me, but i think rpms are more
> trouble than they're worth. never missed them once i moved from to
> slackware.
I hope you're not talking about source tarballs? Some people don't
have a problem compiling every package on their system from source,
but I do. (It takes longer, it wastes system resources, and some
packages just won't compile.)
I don't have a particular problem with binary tarballs. But that's
pretty much just an .rpm with no dependency information.
cbbr...@acm.org
> Garglemonster <gargle...@my-deja.com> writes:
>
> > so don't use rpms.
>
> I don't.
>
> > tarballs will do fine, even on redhat systems.
>
> Sure, but then you can't do things like:
>
> # apt-get update; apt-get upgrade
>
> automatically. For various reasons this may not be a good thing in
> your situation, but for me it's very convenient.
>
> > i don't suppose many will agree with me, but i think rpms are more
> > trouble than they're worth. never missed them once i moved from to
> > slackware.
>
> I hope you're not talking about source tarballs? Some people don't
> have a problem compiling every package on their system from source,
> but I do. (It takes longer, it wastes system resources, and some
> packages just won't compile.)
>
> I don't have a particular problem with binary tarballs. But that's
> pretty much just an .rpm with no dependency information.
Note that the BSD folks cope pretty nicely with "using tarballs,"
albeit with the considerable structuring that they have a pretty
spiffy makefile system called Ports (or OpenPackages) that is fairly
much analagous to apt-get.
The whole "Slackware is better 'cause it's tarballs" thing seems
vastly nonsensical to me.
About all that seems to make sense about it would be the contention:
"Because Slackware does absolutely nothing to help with system
administration, I have to be intimately knowledgeable about every
aspect of how every component is installed, and any tool that gets
in the way of being _utterly_ intimate with that knowledge is utter
loss."
Which essentially represents the claim that every sysadmin needs to
know _everything_ about their system. Which certainly makes upgrading
anything a challenge...
--
(reverse (concatenate 'string "ac.notelrac.teneerf@" "454aa"))
http://www.cbbrowne.com/info/linuxpkgs.html
Beauty is the first test: there is no permanent place in the world for ugly
mathematics.
Dennis Jenkins
>
> so don't use rpms. tarballs will do fine, even on redhat systems.
>
> i don't suppose many will agree with me, but i think rpms are more
> trouble than they're worth. never missed them once i moved from to
> slackware.
>
> g.m.
Same here! If it can't be installed by doing "tar zxf XXX; cd XXX;
./configure; make; make install", then I think twice before installing
it.
--
djen...@usb.com Universal Savings Bank.
Security Administrator, Unix Administrator, Alpha Geek
The three most dangerous things are a programmer with a soldering
iron, a manager who codes, and a user who gets ideas.
Garglemonster
>> tarballs will do fine, even on redhat systems.
Eric> Sure, but then you can't do things like:
Eric> # apt-get update; apt-get upgrade
Eric> ...which will upgrade the easily-upgraded packages on your
Eric> system automatically. For various reasons this may not be a
Eric> good thing in your situation, but for me it's very
Eric> convenient.
ok, fine, but then you can't really complain about the package manager
putting things where it wants to put them.
Eric> I hope you're not talking about source tarballs? Some
Eric> people don't have a problem compiling every package on their
Eric> system from source, but I do. (It takes longer, it wastes
Eric> system resources, and some packages just won't compile.)
i am, but i guess this is a philosophical issue. we'll just have to
agree to disagree.
happing package managing!
g.m.
While you're chewing, think of STEVEN SPIELBERG'S bank account ... his
will have the same effect as two "STARCH BLOCKERS"!
Roger Leigh
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
>
> Somebody, please explain the rational for this (as I see it) stupid
> partitioning scheme.
Diskquotas work on a per-filesystem basis:
roger@whinlatter:~/gimp-print/current$ quota
Disk quotas for user roger (uid 1000):
Filesystem blocks quota limit grace files quota limit grace
/dev/hda7 583200 750000 800000 10448 13000 15000
/usr, /var/spool/(mail|news), /usr/local, /home and other parts of the
directory hierarchy may be nfs exports or mounts used by many
machines.
You might want to mount some filesystems e.g. /usr read-only for
security purposes, and it might be useful for backup purposes to keep
them separate e.g. backup /home daily, but /usr weekly (because it is
rarely modified).
--
Roger Leigh ** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
For GPG Public Key: finger rl...@tower.york.ac.uk or see public keyservers.
Eric P. McCoy
> >>>>> "Eric" == Eric P McCoy <ctr2...@yahoo.com> writes:
> Eric> Sure, but then you can't do things like:
> Eric> # apt-get update; apt-get upgrade
> Eric> ...which will upgrade the easily-upgraded packages on your
> Eric> system automatically. For various reasons this may not be a
> Eric> good thing in your situation, but for me it's very
> Eric> convenient.
> ok, fine, but then you can't really complain about the package manager
> putting things where it wants to put them.
Well, Debian has a file system standard which is fairly sensible and
seems to be well-enforced (so long as the .debs come from an official
mirror). So I know where the package manager will put them, and
that's generally where I put them myself when I have to build them
from the source.
> Eric> I hope you're not talking about source tarballs? Some
> Eric> people don't have a problem compiling every package on their
> Eric> system from source, but I do. (It takes longer, it wastes
> Eric> system resources, and some packages just won't compile.)
> i am, but i guess this is a philosophical issue. we'll just have to
> agree to disagree.
I can see where you're coming from in wanting to have total control.
But I just don't see how it's feasible on a system with several
hundred or thousand installed packages.
And I can always do it your way, too.
Mats Wichmann
:I have noticed that many dedicated server hosting providers partition
Many other answers. Here's my take, roughly the way I present it in a
sysadmin class I teach:
Partitioning allows for: security (mounting key stuff read-only);
performance - parameterize different filesystems for different uses -
or even use different filesystem types; better alignment with backup
strategies; keeping filesystems small enough to fit on a tape; easier
upgrades - OS upgrades typically only affect system areas, user data,
if on a different partition can be left alone; and performance - I can
take two busy filesystems and put them on different disks, probably
making sure they're on the fastest part of the disk - performance is
better at the outer edge of the disk. I can also do things like mirror
key filesystems without having to go to the expense of mirroring
/everything/.
There are some downsides, too: mainly that if you didn't pick the
right sizes, it may bite you later, especially as OS upgrade time.
Logical volume management can be part of the solution to that,
potentially at a cost of performance, esp. if your carefully laid out
scheme now becomes non-optimal due to added space being on the same
spindle (longer seeks). Actually, it seems to me that carving the
disk into pieces and asking LVM to combine those back into bigger
chunks is not the best way to handle it: why not give the whole disks
to the LVM system and let it handle the carving up within the LVM
layer, and then combine one or more of those pieces into filesystems.
I think only HP is doing that in a big way yet....
Mats Wichmann
Perlica
one. How much space do I reserve for each partition? I knew that for /boot
it should be 50 MB. I am new to linux (I installed RH 7.1 on one PC at
office), and I want to install it at home. I am about to change my HDD (20
or 40 GB) and there will be 2GB for WIN 98 and say some 6 - 10 GB for XP.
How should I partition rest of my HDD for RH 7.1? I have 256 MB RAM, and AMD
K6-II 500 MHz.
Ivan
--
---------- NOSPAM email address DO NOT reply ----------
----------------- perlica - at - yahoo - dot - com ------------------
Jean-David Beyer
>
> There were a lot of explanations for posted question, but I have another
> one. How much space do I reserve for each partition? I knew that for /boot
> it should be 50 MB. I am new to linux (I installed RH 7.1 on one PC at
> office), and I want to install it at home. I am about to change my HDD (20
> or 40 GB) and there will be 2GB for WIN 98 and say some 6 - 10 GB for XP.
> How should I partition rest of my HDD for RH 7.1? I have 256 MB RAM, and AMD
> K6-II 500 MHz.
>
your machine has a suitable backup mechanism (such as tape drive), you
might try the following:
Partition it any old way. You might look at this; primarily for machines
with more than one hard drive, but useful.
http://www.ibiblio.org/mdw/HOWTO/Multi-Disk-HOWTO.html
This one may help even more
http://www.ibiblio.org/mdw/HOWTO/mini/Partition/index.html
Anyway, try not to be too obsessive about it. Once you have done any
particular partitionning, run the system for a while. Notice how much
space in each partition you are using. Use df to find out. It will let
you know how much you have, have used, etc. Here is mine:
valinux:jdbeyer[~]$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda8 5249680 1945756 3037248 39% /
/dev/sda1 23302 10137 11962 46% /boot
/dev/sdb1 23302 10126 11973 46% /boot2
/dev/sda3 2016044 229572 1765992 12% /data1
/dev/sdb3 2016044 230112 1765452 12% /data2
/dev/sdb5 6649148 675360 5636024 11% /home
/dev/sda5 1011928 649464 311060 68% /opt
/dev/sda6 132207 682 124699 1% /tmp
/dev/sda7 248895 30429 205616 13% /var
valinux:jdbeyer[~]$
Here is how it is really laid out, according to fdisk:
valinux:jdbeyer[~]$ cat fdisk.out
Disk /dev/sda: 255 heads, 63 sectors, 1116 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sda1 * 1 3 24066 83 Linux
/dev/sda2 4 20 136552+ 82 Linux swap
/dev/sda3 21 275 2048287+ 83 Linux
/dev/sda4 276 1116 6755332+ 5 Extended
/dev/sda5 276 403 1028128+ 83 Linux
/dev/sda6 404 420 136521 83 Linux
/dev/sda7 421 452 257008+ 83 Linux
/dev/sda8 453 1116 5333548+ 83 Linux
Disk /dev/sdb: 255 heads, 63 sectors, 1116 cylinders
Units = cylinders of 16065 * 512 bytes
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 3 24066 83 Linux
/dev/sdb2 4 20 136552+ 82 Linux swap
/dev/sdb3 21 275 2048287+ 83 Linux
/dev/sdb4 276 1116 6755332+ 5 Extended
/dev/sdb5 276 1116 6755301 83 Linux
Many of mine would be useless for you (I have 2 9 GByte hard drives).
There are two swap partitions of about 125 Megabytes each, one on each
drive. You almost certainly do not need /data1 and /data2 nor would you
need /boot2 (pretty much a copy of /boot, but on the other drive).
When you notice that some partition is almost full, or too full to
allocate a needed file, you will wish to repartition. So save everything
on backup. Make at least two backups of everything and verify them.
Then decide what space you wish to allow for each, and repartition. Then
restore the files from backup. It is difficult to repartition things
like the / partition without needing to reinstall. But that is OK: you
do have the backups, right?
When I first set up Linux (RHL 5.0) on my other (smaller) machine, I
used about 16 partitions. That seems to be far too many. Each time I
install a new release on that machine, I reduce the number of
partitions. I would not go to the extreme of two: swap and / (everything
else).
This machine has 13 partitions, but it has two large drives (and I do
not run Microsoftware on it), so 13 makes sense for me. Most people
could do with 9, I guess, since they would not need /data1, /data2,
/boot2, and one swap partition should be enough if you have enough RAM
(I have 512Megabytes). I have not swapped since I booted the machine
over a week ago. When I ran the 2.2.14 kernel, it swapped up to about 30
megabytes, but the paging rate was extremely low (less than one per
hour). This "new" kernel (2.2.18pre11-va2.1smp) seems to swap much less.
--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 73926.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 9:00am up 9 days, 15:57, 3 users, load average: 3.12, 3.14, 3.08
Black Dragon
: Somebody, please explain the rational for this (as I see it) stupid
: partitioning scheme.
Just one example coined from my personal experiences:
Have you ever wanted to move "C:\>Program Files" to another, larger
partition on another disk in a Windows machine? Ever tried it? Say
you run out of storage space in /usr, *nix's sort of equivalent to
\Program Files. No problem. Install another hard drive in the machine,
partition and format it, mount it temporarily, copy the data from the
existing /usr to the new larger partition, erase the contents of the
old /usr to free up space on the existing partition, and re-mount the
new big partition on /usr. No muss, no fuss, just very flexible and
logical system administration.
Also, I used only Dos and Windows for nine years prior to using Linux
for the past three, and I *always* partitioned my drives as I think
installing everything on one big fat honking partition is incredibly
stupid. The OS's went on C:, programs were installed on D:, user data
was stored on E:, etc. That way when the OS got munged up (Windows?
Never! ;-) or I wanted to upgrade, I could do a clean install on a
freshly formated partition without blowing away my existing programs
and data. Same goes for *nix, but you don't have to contend with the
cryptic drive letters and re-installing / re-registering broken
applications.
* Remember 09-11-01 <URL:http://roadrage.myip.org/rest-in-peace>
--
Black Dragon | Its really terrible when the FBI arrested a
* Free Speech | hacker, who visited the USA with a peaceful
* Free Dmitry Sklyarov! | mission -- to share his knowledge with the
<URL:http://freesklyarov.org> | American Nation. (Ilya V. Vasilyev)
Kasper Dupont
>
> There were a lot of explanations for posted question, but I have another
> one. How much space do I reserve for each partition? I knew that for /boot
> it should be 50 MB. I am new to linux (I installed RH 7.1 on one PC at
> office), and I want to install it at home. I am about to change my HDD (20
> or 40 GB) and there will be 2GB for WIN 98 and say some 6 - 10 GB for XP.
> How should I partition rest of my HDD for RH 7.1? I have 256 MB RAM, and AMD
> K6-II 500 MHz.
I have been doing this in a little unusual way, it is a little
difficult to set up and I still need to figure out a few details.
But when done correctly this system should become easy to
backup and restore.
First of all I want to backup / and /home, so I make each a
500 MB partition. That way I'm sure they will always fit on a CD
each.
I'm not sure in this setup whether it is a good idea to make
/boot a seperate partition. The / partition is already small
enough to use as boot partition without problems, but one might
some day want to use another filesystem on / that cannot be
used for /boot. If I choose to make /boot a seperate partition
it should fit together with / on a single CD.
To be able to make backups of / (and /boot) without problems
related to mount points I mount it in a seperate location
using bind mounts. (A 2.4.x feature). Though to avoid confusing
the init scripts I do this by mounting the block device twice
rather than using the bind option, the fstab entries could look
like this:
/dev/hda1 / ext2 defaults 1 1
/dev/hda1 /mnt/root ext2 defaults 0 0
or like this:
/dev/hda5 / ext2 defaults 1 1
/dev/hda1 /boot ext2 defaults 1 2
/dev/hda5 /mnt/root ext2 defaults 0 0
/dev/hda1 /mnt/root/boot ext2 defaults 0 0
Most people will of course also want a swap partition.
I don't want to backup /usr, so I will make that partition use
the rest of the disk space. I don't want to backup /tmp either
so that go on the same partition as /usr, this is done by
creating a /usr/local/tmp directory and mount that as /tmp
with a bindmount.
/usr/local/tmp /tmp none bind 0 0
But although I don't want to backup /usr i still want to backup
/usr/local, so that go on the root partition with an additional
bindmount:
/mnt/root/usr/local /usr/local none bind 0 0
The entries for /usr and /home are just normal entries in the
fstab, I place them before the bind entries. The removable
devices are as usual placed last in fstab.
I then make a bootable floppy image that will contain a kernel
and will use the CD drive as root fs. The most intuitive
location for this image is in the /boot directory. This image
is used when backing up the root filesystem to CD, that way I
will have a bootable CD that will work a little similar to my
runing system. This backup is not made from / but from the
alternate mountpoint /mnt/root.
The /home partition is backed up to another CD. Nothing special
about this, that CD is not going to be bootable.
The ISO images is not going to use the entire 650MB space, I
use the rest of the space for redundant encoding of the data,
that way I will still have a chance to restore my data in case
of a few bad sectors. (If anybody is interested I will upload
my redundant encoding algorithm to an http server, there is not
yet an automated recovery algorithm it is a lot of work to do
by hand.) The redundant encoding is no excuse from always
keeping two backups of each partition and verifying them.
To restore the system the following procedure is to be used:
1. Boot from the backup of /
2. Create and format partitions.
3. Mount / and /boot and copy files from /mnt/cdrom to harddisk.
4. Run lilo with a -r option to make harddisk bootable.
5. Boot system from harddisk.
6. Recreate /usr from original install disks and information in
package database. (I still consider how to write a program
to do that on RPM based systems, it should be possible, I
just need to figure out the best and easiest way.)
7. Restore /home in the obvious way.
A few notes:
I have made a copy of a few files from /usr/lib in the
directory /mnt/root/usr/lib. Because they are needed by
rpm, and I want to use rpm even if the /usr partition is
missing.
No need to backup /mnt/root and /home at same intervals.
A few utilities normally located in /usr might be needed
even when /usr is not available. They must be copied to
/mnt/root/usr/local.
To setup such a system first install with the partitions
/
/boot (optionally)
/home
/usr
swap
The fstab is then setup by hand, and after a reboot the
contents of /usr/local is then moved by hand to
/mnt/root/usr/local. Some other files from /usr must
also be copied to /mnt/root/usr.
--
Kasper Dupont
A. Tsakiris
> I have noticed that many dedicated server hosting providers partition
> the disk as boot, usr, var, and home. Why?
[snip]
>
> Somebody, please explain the rational for this (as I see it) stupid
> partitioning scheme.
I'm no expert, but I've come across some reasons while trying to
set up and secure a Linux system. Using separate partitions,
such as those that you mention above, provides flexibility in
securing a system. Different options (in fstab) can be used for
different partitions.
For instance, from the Security HOWTO:
- There shouldn't be any reason to allow SUID/SGID programs in
users' home directories.
- If you're mounting filesystems using a network filesystem, you
can set appropriate restrictions.
- Files containing logs (typically on var) can be easily
protected.
Check out the Security HOWTO for more details.
--
A. Tsakiris
Eric P. McCoy
> There were a lot of explanations for posted question, but I have another
> one. How much space do I reserve for each partition? I knew that for /boot
> it should be 50 MB. I am new to linux (I installed RH 7.1 on one PC at
> office), and I want to install it at home. I am about to change my HDD (20
> or 40 GB) and there will be 2GB for WIN 98 and say some 6 - 10 GB for XP.
> How should I partition rest of my HDD for RH 7.1? I have 256 MB RAM, and AMD
> K6-II 500 MHz.
Well, it varies considerably depending on your situation. But this
works for me (right now):
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda7 497829 440308 31819 94% /
/dev/system/usr 2097084 1405724 691360 68% /usr
/dev/system/var 2584492 1892928 691564 74% /var
/dev/system/home 20970876 17554264 3416612 84% /home
/dev/system/export 17825244 14169760 3655484 80% /export
Root normally wouldn't be so full; I've just been too lazy to fix it.
The reason /var is so large is that it contains the root filesystem
for some diskless clients as well as the disk-based stuff for a
database. /export is a Samba shared disk (Linux doesn't use it at
all). Part of the reason /home is so huge is that it has MP3s and the
like.
Kasper Dupont
>
> "Perlica" <pe...@mikalaza.com> writes:
>
> > There were a lot of explanations for posted question, but I have another
> > one. How much space do I reserve for each partition? I knew that for /boot
> > it should be 50 MB. I am new to linux (I installed RH 7.1 on one PC at
> > office), and I want to install it at home. I am about to change my HDD (20
> > or 40 GB) and there will be 2GB for WIN 98 and say some 6 - 10 GB for XP.
> > How should I partition rest of my HDD for RH 7.1? I have 256 MB RAM, and AMD
> > K6-II 500 MHz.
>
> Well, it varies considerably depending on your situation. But this
> works for me (right now):
>
> Filesystem 1k-blocks Used Available Use% Mounted on
> /dev/hda7 497829 440308 31819 94% /
> /dev/system/usr 2097084 1405724 691360 68% /usr
> /dev/system/var 2584492 1892928 691564 74% /var
> /dev/system/home 20970876 17554264 3416612 84% /home
> /dev/system/export 17825244 14169760 3655484 80% /export
>
> Root normally wouldn't be so full; I've just been too lazy to fix it.
I just wonder what can take up so much space in /?
On my RH7.1 I have only 81M on my / partition, and
it even includes /var.
> The reason /var is so large is that it contains the root filesystem
> for some diskless clients as well as the disk-based stuff for a
> database. /export is a Samba shared disk (Linux doesn't use it at
> all). Part of the reason /home is so huge is that it has MP3s and the
> like.
Well I think most people will be able to put lots
of stuff in /home, the only problem is that it is
probably the most important stuff to backup.
>
> --
> Eric McCoy <ctr2...@yahoo.com>
>
> "I woke up this morning and realized what the game needed: pirates,
> pimps, and gay furries." - Rich "Lowtax" Kyanka
--
Kasper Dupont
Robert Heller
In a message on Sat, 29 Sep 2001 12:20:34 +0200, wrote :
"> There were a lot of explanations for posted question, but I have another
"> one. How much space do I reserve for each partition? I knew that for /boot
"> it should be 50 MB. I am new to linux (I installed RH 7.1 on one PC at
"> office), and I want to install it at home. I am about to change my HDD (20
"> or 40 GB) and there will be 2GB for WIN 98 and say some 6 - 10 GB for XP.
"> How should I partition rest of my HDD for RH 7.1? I have 256 MB RAM, and AMD
"> K6-II 500 MHz.
This is what *I* would do:
/ 128-256meg
<swap> 128-512meg
/usr 2-3gig
/var 128-256meg
/home whatever is left
I would only bother with a /boot file system if there was an issue with
the 1024 cylinder limit. One thought:
/dev/hda1 2gig FAT (Win98) (C:, /Win98)
/dev/hda2 50meg Ext2 (/boot)
/dev/hda3 6-10gig FAT32 or NTFS (XP) (D:, /WinXP)
/dev/hda4 *extended* (rest of disk)
/dev/hda5 128-256meg Ext2 (/)
/dev/hda6 128-512meg <swap>
/dev/hda7 2-3gig Ext2 (/usr)
/dev/hda8 128-256meg Ext2 (/var)
/dev/hda9 *remainder* Ext2 (/home)
This should make sure that all of the boot code (C:, /boot) lives below
cylinder 1024. I'm guessing that XP is like NT/2K when co-installed with
Win9x -- the boot-loader lives as a part of the autoexec.bat on the MS-DOS
(Win98) system.
">
"> Ivan
">
"> --
"> ---------- NOSPAM email address DO NOT reply ----------
"> ----------------- perlica - at - yahoo - dot - com ------------------
">
">
">
--
\/
Robert Heller ||InterNet: hel...@cs.umass.edu
http://vis-www.cs.umass.edu/~heller || hel...@deepsoft.com
http://www.deepsoft.com /\FidoNet: 1:321/153
Victor Wagner
: Garglemonster <gargle...@my-deja.com> writes:
: I don't.
:> tarballs will do fine, even on redhat systems.
: Sure, but then you can't do things like:
: # apt-get update; apt-get upgrade
Sure, but distribution size is limited - there are just three binary CDs,
and number of packages on
particular system is limited even more. For intstance I have about
700 packages on my home system, and it is Jack-of-all-trades.
1Gb /usr does the job. On most more specialized systems like web-servers
or office workstations 300-700Mb is enough.
Just don't install things you don't need.
Really, threshold between "to partition" and "not to partition"
lies around 1Gb for multi-purpose systems like notebooks.
(i.e. if you have more than 1Gb of total disk space, it is better to
partition)
For highly-specialized systems such as dedicated DNS servers or
routers/firewalls I'd rather partition even 240Mb disk.
: I hope you're not talking about source tarballs? Some people don't
: have a problem compiling every package on their system from source,
: but I do. (It takes longer, it wastes system resources, and some
: packages just won't compile.)
Typically, one have more problems installing binaries which are not
from one's distribution. You might just not notice it since you are
Debian user, and Debian includes almost everything.
Even with Debian I have deb-src lines in my sources,list pointing
to unstable when deb lines to stable and use
apt-get -b source
to get package which exists only in unstable.
Typically it either goes smoothly or requires few changes in
debian/rules to get package from unstable compilied in stable,
while binary packages from unstable just do not work in stable
due to different glibc versions.
BTW, if program doesn't compile, I usially became very suspicious about
it. Probably it has more bugs than just "not to compile".
--
echo "Congratulations. You aren't running Eunice."
-- Larry Wall in Configure from the perl distribution
Perlica
news:871ykpe...@providence.local.net...
|
| Well, it varies considerably depending on your situation.
Would it be a good idea to mount one fat 32 partition (that can be accessed
from all OS-s) as /home?
Kasper Dupont
>
> "Eric P. McCoy" <ctr2...@yahoo.com> wrote in message
> news:871ykpe...@providence.local.net...
> |
> | Well, it varies considerably depending on your situation.
>
> Would it be a good idea to mount one fat 32 partition (that can be accessed
> from all OS-s) as /home?
No, fat 32 lacks some important features:
- ownership
- permitions
- symlinks
- lots of others that you might be able to live
without as long as you only use this for /home.
If you had a way to simulate them on top of fat 32
it could actually work, a little like UMSDOS. But
I still wouldn't call the idea good.
--
Kasper Dupont
Robert Heller
In a message on Sun, 30 Sep 2001 10:02:49 +0200, wrote :
"> "Eric P. McCoy" <ctr2...@yahoo.com> wrote in message
"> news:871ykpe...@providence.local.net...
"> |
"> | Well, it varies considerably depending on your situation.
">
"> Would it be a good idea to mount one fat 32 partition (that can be accessed
"> from all OS-s) as /home?
You would do a whole lot better to mount a fat(32) partition as
'transfer' file system. Fat(32) has *no* file protection: no ownership
or permissions are possible. This a a *major* security problem. You
can't have symbolic links on a fat(32) file system (what *LINUX* calls
symbolic links). Note that things like webpages and anon ftp files live
on /home (by default). If you are running either of these servers on
your homw box, they won't work right if /home is a fat32. It is also
*harder* to (intelligently) backup a fat32 file system under Linux.
Don't mount a FAT32 file system as /home!
">
"> --
"> ---------- NOSPAM email address DO NOT reply ----------
"> ----------------- perlica - at - yahoo - dot - com ------------------
">
">
">
Roger Leigh
> Typically, one have more problems installing binaries which are not
> from one's distribution. You might just not notice it since you are
> Debian user, and Debian includes almost everything.
>
> Even with Debian I have deb-src lines in my sources,list pointing
> to unstable when deb lines to stable and use
> apt-get -b source
> to get package which exists only in unstable.
>
> Typically it either goes smoothly or requires few changes in
> debian/rules to get package from unstable compilied in stable,
> while binary packages from unstable just do not work in stable
> due to different glibc versions.
>
> BTW, if program doesn't compile, I usially became very suspicious about
> it. Probably it has more bugs than just "not to compile".
I have been having more and more problems lately compiling unstable
source on stable. However, this it not because they are in any way
buggy. When stable (potato) was newly released, unstable had not
diverged much, and so everything would build properly. Now there have
been several new Standards-Versions, new lintian, and many more new
packages. Because of this the Debianised source may no longer
compile due to things such as missing Build-Depends, control fields
not recognised (e.g. Build-Depends-Indep) or packages not available
that are needed to build such as new tetex, new perl, new libs etc.
YMMV of course, depending on exactly how much of your system is
compiled from unstable.
Victor Wagner
: "Eric P. McCoy" <ctr2...@yahoo.com> wrote in message
: news:871ykpe...@providence.local.net...
: |
: | Well, it varies considerably depending on your situation.
: Would it be a good idea to mount one fat 32 partition (that can be accessed
: from all OS-s) as /home?
Not at all.
FAT32 if functionally impaired filesystem - no permissions, no links,
no fifos.
Some wide-used programs extensively use symlinks and fifos in their
settings directories, which they create at ${HOME}.
Other programs use link/unlink calls instead of rename on working files.
I cannot believe that it is possible to work in Unix effectively without
custom scripts in ${HOME}/bin
All this things broke if you use FAT for home directories.
If you have more than one user on the machine (which is the case for
most home computers) things become even worse.
--
It's possible that I'm just an idiot, and don't recognize a sleepy
slavemaster when I see one.
-- Larry Wall in <1997080403...@wall.org>
Victor Wagner
wrote:
: Perlica wrote:
: No, fat 32 lacks some important features:
: - ownership
: - permitions
: - symlinks
: - lots of others that you might be able to live
: without as long as you only use this for /home.
Not, if you use fvwm or kde. I don't know about gnome,
but have suspicion that it also need some fifos in
${HOME}/.gnome
: If you had a way to simulate them on top of fat 32
: it could actually work, a little like UMSDOS. But
There was also patch to kernel which provides uvfat filesystem
which has long file names compatible with Windows but simulates
all other features of normal filesystem same way UMSDOS does.
UMSDOS defeats all purpose of "accessible for all OS" filesystem,
becouse file names wouldn't be same
--
It's the Magic that counts.
-- Larry Wall on Perl's apparent ugliness
Kasper Dupont
It is true that UMSDOS naming convention is not good.
I didn't that UMSDOS was the solution, I said something
like a little like UMSDOS. I didn't know if there was
such a thing as uvfat, but that was exactly what I had
in mind.
>
>
> --
> It's the Magic that counts.
> -- Larry Wall on Perl's apparent ugliness
--
Kasper Dupont
Perlica
Victor Wagner
: vi...@wagner.rinet.ru (Victor Wagner) writes:
: I have been having more and more problems lately compiling unstable
: source on stable. However, this it not because they are in any way
: buggy. When stable (potato) was newly released, unstable had not
: diverged much, and so everything would build properly. Now there have
: been several new Standards-Versions, new lintian, and many more new
: packages. Because of this the Debianised source may no longer
Typically, it is easy to fix. Only thing which really have changed
is that dh_installmanpages was obsoleted by dh_installman
: compile due to things such as missing Build-Depends, control fields
: not recognised (e.g. Build-Depends-Indep) or packages not available
: that are needed to build such as new tetex, new perl, new libs etc.
I doubt that there is any really good program which would need
"new tetex" rather than "some tetex" and "new perl" rather than
"some perl above 5.003". So, real problems can be encountered only
with Gtk and Qt programs. It is one of main reasons why I hate these
toolkits. They are changing too rapidly to be useful. In comparation,
Tk is binary-compatible between all version starting with I think
8.2 (may be even with 8.1), and Motif/Lesstif has stable interface
for ages.
--
If you want to program in C, program in C. It's a nice language. I
use it occasionally... :-)
-- Larry Wall in <75...@jpl-devvax.JPL.NASA.GOV>