On Tue, 18 Jan 2005, David Newcomb wrote:
> When the machine boots up the partition table is read.
> For each partition there is a superblock which contains all the inodes
> and addressing information for that partition.
>
> If you have 1 root partition at the start and (therefore faster outermost
> rim of the disc) then everything that needs to be read or writen can
> be accessed extremly fast. Only 1 super node structure is held in memory.
> All the information can be read in a series of sequental reads.
>
> If you have serveral partitions then there is a superblock structure
> for each of the partitions, which are spread across the whole disc.
> Read & write operations cause the disc heads to jump to each of the
> superblock structures for each partition as they read and write.
Naw, I still don't buy it. If LVM has been measured as having negligible
impact on performance (LVM essentially has all logical volumes being
assembled from many 32MByte extents, potentially scattered all over the
disc(s)), then a traversing a handful of entries in a kernel structure to
represent all the mounted filesystems should make even /less/ difference.
I'd also expect frequently-referenced things like superblocks to remain in
the buffer cache, given sufficient memory. David Rusling's document on the
kernel seems to confirm that this is the case
<http://www.tldp.org/LDP/tlk/fs/filesystem.html>. Further, the VFS caches
directory lookups independently.
> The test [if you can call them that:)] was 2 complete installs on
> the same machine. One with 1 root partition and the other with
> serveral partition. We noted that machine was much faster with just
> one root partition.
Faster doing _what_ ?
I can well imagine that copying or moving many (or large) files between
partitions is slower than performing the same operation within a single
partition using the same areas of the disc. I'd also expect some
applications to run slower if they're working with two partitions (e.g.
ccache, which will use hardlinks if the compilation directory is on the same
filesystem as the cache directory, but will copy files otherwise). Further,
if you weren't noting where on the disc files were allocated, I can imagine
that operations solely within a single partition are slower if the same
operations are performed on a partition that's physically located towards
the hub of the disc.
As it happens, some quick tests show it isn't even as bad as I was
pessimistically expecting. Here are some crude tests:
$ mkdir test
$ mkdir /burn2/test
$ mkdir /spare/test
$ mount | grep burn2
/dev/hdg6 on /burn2 type ext2 (rw)
$ mount | grep 'spare '
/dev/hde3 on /spare type ext3 (rw)
$ mount | grep scratch # This is logical volume on a md RAID1 pair
/dev/mapper/200GVolGroup01-scratch on /scratch type ext3 (rw)
$ du -sch corpus/
562M corpus/
562M total
$ time cp -ar corpus/ test/ # once to cache as much source material as we
can
real 0m22.962s
user 0m0.115s
sys 0m1.760s
$ rm -rf test/*
$ time cp -ar corpus/ test/
real 0m23.128s
user 0m0.115s
sys 0m1.740s
$ time cp -ar corpus/ /burn2/test/
real 0m14.803s
user 0m0.103s
sys 0m1.766s
$ time cp -ar corpus/ /spare/test/
real 0m25.775s
user 0m0.136s
sys 0m2.525s
$ time cp -ar corpus/ /scratch/test/
real 0m28.996s
user 0m0.136s
sys 0m2.492s
Voila. No significant difference in performance, other than a) when copying
from a partition on one disc, to a partition on another - which is faster as
expected as less seeking is required and b) when copying from to a
journalled ext3 fs on LVM on RAID1 at the slow end of the disc, which is
slightly slower (not very surprising!).
Or are you saying that if I unmounted all the other partitions, these tests
will run faster?
Based on the tests I've done so far, I'm of the opinion that either the
tests were unscientific (in that they didn't control all significant
variables), or that there was something wrong with the hardware or the way
it was configured.
> Be sides the only reason they invented partitioning was because :
> 1. they wanted to address a whole disk using a fixed size address
> (can't remember what size). Remember all that trouble with LBA?
> 2. The partition segrates all the pieces of disc into managable
> chunks so that if part of the disk becomes currupted that file
> allocation tables are more distributed.
You're quite correct that partitioning is essentially a management and
convenience feature. There are, however, many more advantages than those you
listed (<http://www.hccfl.edu/pollock/AUnix1/Partitioning.htm> is a more
comprehensive list). Even if there /were/ a significant performance penalty,
there are still /many/ overwhelmingly positive reasons to choose to
partition on a general purpose system, not least the administration time
that can be saved as a result (e.g. having to recover from backup after a
careless rm -rf in a directory that could otherwise be mounted read-only)
> All the rest it overhead.
>
> Regards,
> David.
Best Regards,
Alex.
--
Alex Butcher Brainbench MVP for Internet Security: www.brainbench.com
Bristol, UK Need reliable and secure network systems?
PGP/GnuPG ID:0x271fd950 <http://www.assursys.com/>