On Tue, 10 Sep 2002, Smitty wrote:
> I noticed Russ Herrold puts each directory on a seperate extended partition.
> Does this have advantages over keeping /bin, /sbin, /lib, /etc/, /usr, and
> /opt together on the / partition?
Smitty does not say, but I think he is referring to a piece I
have at:
http://www.owlriver.com/tips/rsync-cookbook.txt
which states:
I usually hang:
1 /boot
2 /
3 <swap>
4 <extended>
5 /usr
6 /tmp
7 /var
8 /var/log
9 /var/spool
10 /home
... for reasons not relevant here.
-----------------------------------------
And to respond to Smitty's question, it _is_ relevant to work
through issues in partitioning theory and strategy -- these
are matters of taste to some degree, so I'll be a bit wordy.
I. With the customary fdisk, which produce partitioning
information which modern BIOS are set to understand, there are
four 'Primary' partitions maximum, with the potential for just
one 'Extended' partition. In the quoted section above,
partitions 1, 2, 3 are all conventional Linux type 82 or type
83 Primary partitions.
Partition 4 is always Extended for me, simply so I can
remember where it is. Sometimes (the Compaq management
partition at partition 3, and Sandisk SmartMedia at partition 4,
and the Iomega Zip media at partition 4), the initial vendor's
scheme needs to be accomodated.
II. There is a hard limit of 14, or 15 total partitons owing
to the space of the data structure which the BIOSes understand
in that initial 512 byte sector on a hard drive (I forget at
the moment), and so I try to hold total partitions under 12.
III. Let's take a peek at the mountpoints in / ('slash', the
root partition) of a live system:
[root@oldnews root]# cd /
[root@oldnews /]# ls
bin dev home lib mnt proc sbin usr
boot etc initrd lost+found opt root tmp var
IV. Slash HAS to have /dev, /etc, /root, /sbin, in most
Linux distribution approaches. The mountpoints /bin, /boot,
/home, /lib, /mnt, /proc, /tmp, and /var are by and large not
used in attaining runlevel 1, which is the control item which
drives this analysis -- /lost+found is present in every
partition which is ext[23] formatted, and should re-created if
missing, audited if it contains content.
/dev to carry the block devices to mount the drives
/etc to see the /etc/fstab and the initscripts and other
config data
/root for reasons which are unclear -- this directory should
be largely empty anyway in good admin practice
/sbin to have some (largely) static linked tools
Using "du --one /sbin" on each required directory for the root
partition will yield the size needed for '/' -- it is a
smallish figure --
As I recall, parts of /lib are needed as well -- probably
/lib/modules in most Linux approaches, because of the loadable
kernel modules (LKMs) being needed fairly soon after boot
time, as networking is being set up (most network drivers are
Loadable Kernel Modules, as most recent distributions
presently structure things.)
It is posible to avoid this with a static kernel, holding all
needed modules -- but inefficient. There may be others, but I
do not think so ...
V. The sizing and layout sequence of the remaining partitions
and sub partitions in partitioning strategy are driven by the
tasking for the host in question. These questions should be
considered:
The FHS
http://www.pathname.com/fhs/
and the LSB are a familiar topic to Sluggers --
http://www.owlriver.com/projects/SLUG/
and this is a largely 'political' discussion, with technical
overtones. But looking at the file location recommendations
offers guidance -- /var/ is much more important than it used
to be.
If you are installing lots of KDE native or SuSE content, an
/opt partition may be separately needed.
Backup: How important is the data to be saved. Will it fit
the recovery media you have available -- a tape, a CD,
rsyncing to another hard drive, are all options -- and can you
complete the backup within any backup window. How current
does the backup need to be?
Raiding: I had a drive go bad on a Dell PERC hardware raid
array the other week; I noticed it in the syslog messages,
and Dell shipped the warranty replacement right (Nice folks --
recommended). I dropped the drive in, and it rebuilt itself
for the next couple hours. The data contained within the
raid container was backed up -- but it would have taken most
of a day to piece it back together. Which leads to ...
Recovery: By sizing to facilitate recovery, if there had been
a catastrophic failure, tape roll time on a restore can be
held to a minimum, and you can be back online faster -- small
partitions facilitate that.
Usage patterns: Is the data serially written and read Genome
data, or randomly read/write accessed. If serial, a fat
partition 5400 RPM IDE drive is indicated. If it is a news
article spool for an ISP, lots of smaller partitions on
different spindles, SCSI head management will keep the drives
from beating itself to death and allow io induced waits to be
held to a minimum.
----------
VI. Production class of machine
On a production nameserver, no separate /home partition is
used; on a desktop, I may have /home filled with several
hundred meg of ogg files of audio CD's I have ripped from my
collection for background coding music (at the moment, the
Ryko 'The Jimi Hendrix Experience - Live at Winterland';
before that, Rounder's Alison Krauss and Union Station 'So
Long So Wrong')
On a loghost, /var/log/ is endless -- on a mail host,
/var/spool/ -- an FTP server, /var/ftp/ -- and so it goes.
The news-server probably has a /var/spool/news/alt/binaries/
all its own.
One develops a feel -- I plan on a 3 x 5 card as I sit down to
plan a build. And after a few weeks as the usage pattern
develops, if it is important I check with the 'du' command for
any partition over 90 or under 20 per cent, and move the
content off to a holding drive and then back with rsync after
adjusting partitioning.
VII. The desktop I am writing this on? It is the non-spool
drive off of an old news-server and I have not gotten
irritated enough to repartition
[herrold@oldnews SPECS]$ df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/hda2 165950 91048 66334 58% /
/dev/hda1 29249 4511 23228 17% /boot
/dev/hda9 1984240 1675824 207620 89% /home
/dev/hda7 488006 30 462778 1% /tmp
/dev/hda5 2480320 1927384 426940 82% /usr
/dev/hda6 488006 243204 219604 53% /var
/dev/hda8 488006 255411 207397 56% /var/spool
/dev/hda10 488006 43674 419134 10% /var/spool/autorpm
none 127888 0 127888 0% /dev/shm
[herrold@oldnews SPECS]$
and I feel cramped on occasion in /home/ as I am building as
RPMs from source as non-root
http://www.rpm.org/hintskinks/buildtree/
/opt/ is really a soft link ./usr/bin/opt for the need
developed, and I had some space in /usr/ going to
waste -- We saw it above, and it is empty now, so
I won't replace it.
/boot/ is way too small -- It will be 150M next time
/var/spool/ is full of some remote content I needed to stash
a copy of quickly, and will go away.
/var/spool/autorpm/ is big, for I develop in that space and
is unnecessary generally
and I would throw the extra space into /home/
Hope this helps.
-- Russ Herrold
(Parts of this analysis were discussed with James Gaston on
the list over lunch, and I thank him for his help is making it
a better presentation.)
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:12:46 EDT