Okay, so what partitions do you need? Well, some operating systems do not believe in booting from logical partitions for reasons that are beyond the scope of any sane mind. So you probably want to reserve your primary partitions as boot partitions for your MS-DOS, OS/2 and Linux or whatever you are using. Remember that one primary partition is needed as an extended partition, which acts as a container for the rest of your disk with logical partitions.
Booting operating systems is a real-mode thing involving BIOSes and 1024 cylinder limitations. So you probably want to put all your boot partitions into the first 1024 cylinders of your hard disk, just to avoid problems. Again, read the "large-disk" Mini-Howto for the gory details.
To install Linux, you will need at least one partition. If the kernel is loaded from this partition (for example by LILO), this partition must be readable by your BIOS. If you are using other means to load your kernel (for example a boot disk or the LOADLIN.EXE MS-DOS based Linux loader) the partition can be anywhere. In any case this partition will be of type 0x83 "Linux native".
Your system will need some swap space. Unless you swap to files you will need a dedicated swap partition. Since this partition is only accessed by the Linux kernel and the Linux kernel does not suffer from PC BIOS deficiencies, the swap partition may be positioned anywhere. I recommed using a logical partition for it (/dev/?d?5 and higher). Dedicated Linux swap partitions are of type 0x82 "Linux swap".
These are minimal partition requirements. It may be useful to create more partitions for Linux. Read on.
If you have decided to use a dedicated swap partition, which is generally a Good Idea [tm], follow these guidelines for estimating its size:
So for a configuration with 16 MB RAM, no swap is needed for a minimal configuration and more than 48 MB of swap are probably useless. The exact amount of memory needed depends on the application mix on the machine (what did you expect?).
Summary: Put your swap on a fast disk with many heads that is not busy doing other things. If you have multiple disks: Split swap and scatter it over all your disks or even different controllers.
Even better: Buy more RAM.
Disk space is administered by the operating system in units of blocks and fragments of blocks. In ext2, fragments and blocks have to be of the same size, so we can limit our discussion to blocks.
Files come in any size. They don't end on block boundaries. So with every file a part of the last block of every file is wasted. Assuming that file sizes are random, there is approximately a half block of waste for each file on your disk. Tanenbaum calls this "internal fragmentation" in his book "Operating Systems".
You can guess the number of files on your disk by the number of allocated inodes on a disk. On my disk
# df -i
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda3 64256 12234 52022 19% /
/dev/hda5 96000 43058 52942 45% /var
there are about 12000 files on
/ and about 44000 files on
At a block size of 1 KB, about 6+22 = 28 MB of disk space are
lost in the tail blocks of files. Had I chosen a block size of
4 KB, I had lost 4 times this space.
Data transfer is faster for large contiguous chunks of data, though. That's why ext2 tries to preallocate space in units of 8 contigous blocks for growing files. Unused preallocation is released when the file is closed, so no space is wasted.
Noncontiguous placement of blocks in a file is bad for performance, since files are often accessed in a sequential manner. It forces the operating system to split a disk access and the disk to move the head. This is called "external fragmentation" or simply "fragmentation" and is a common problem with DOS file systems.
ext2 has several strategies to avoid external fragmentation. Normally fragmentation is not a large problem in ext2, not even on heavily used partitions such as a USENET news spool. While there is a tool for defragmentation of ext2 file systems, nobody ever uses it and it is not up to date with the current release of ext2. Use it, but do so on your own risk.
The MS-DOS file system is well known for its pathological managment of disk space. In conjunction with the abysmal buffer cache used by MS-DOS the effects of file fragmentation on performance are very noticeable. DOS users are accustomed to defragging their disks every few weeks and some have even developed some ritualistic beliefs regarding defragmentation. None of these habits should be carried over to Linux and ext2. Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% of free space on a disk.
The MS-DOS file system is also known to lose large amounts of disk space due to internal fragmentation. For partitions larger than 256 MB, DOS block sizes grow so large that they are no longer useful (This has been corrected to some extent with FAT32).
ext2 does not force you to choose large blocks for large file systems, except for very large file systems in the 0.5 TB range (that's terabytes with 1 TB equaling 1024 GB) and above, where small block sizes become inefficient. So unlike DOS there is no need to split up large disks into multiple partitions to keep block size down. Use the 1 KB default block size if possible. You may want to experiment with a block size of 2 KB for some partitions, but expect to meet some seldom exercised bugs: Most people use the default.
With ext2, Partitioning decisions should be governed by backup considerations and to avoid external fragmentation from different file lifetimes.
Files have lifetimes. After a file has been created, it will
remain some time on the system and then be removed. File
lifetime varies greatly throughout the system and is partly
dependent on the pathname of the file. For example, files in
/usr/bin and similar directories are
likely to have a very long lifetime: many months and above.
/home are likely to have a medium lifetime: several
weeks or so. File in
/var are usually short lived: Almost no
/var/spool/news will remain longer than a few days,
/var/spool/lpd measure their lifetime in minutes or
For backup it is useful if the amount of daily backup is smaller than the capacity of a single backup medium. A daily backup can be a complete backup or an incremental backup.
You can decide to keep your partition sizes small enough that they fit completely onto one backup medium (choose daily full backups). In any case a partition should be small enough that its daily delta (all modified files) fits onto one backup medium (choose incremental backup and expect to change backup media for the weekly/monthly full dump - no unattended operation possible).
Your backup strategy depends on that decision.
When planning and buying disk space, remember to set aside a sufficient amount of money for backup! Unbackuped data is worthless! Data reproduction costs are much higher than backup costs for virtually everyone!
For performance it is useful to keep files of different
lifetimes on different partitions. This way the short lived
files on the news partition may be fragmented very heavily.
This has no impact on the performance of the