The Linux Partition mini-HOWTO by Kristian Koehntopp, kris@schulung.netuse.de v1.0, 10 September 1996 There are several things to take into considerations when you decide how to partition you disk and where to put these partitions. HOW LARGE SHOULD MY SWAP SPACE BE? ================================== Regarding swap partitions there are the following guidelines: 1. In Linux RAM and swap space add up (This is not true for all Unices). For example, if you have 8 MB of RAM and 12 MB swap space, you have a total of about 20 MB virtual memory. 2. When sizing your swap space, you should have at least 16 MB of total virtual memory. So for 4 MB of RAM consider at least 12 MB of swap, for 8 MB of RAM consider at least 8 MB of swap. 3. When sizing swap space, keep in mind that too much swap space may not be useful at all. Every process has a "working set". This is a set of in-memory pages which will be referenced by the processor in the very near future. Linux tries to predict these memory accesses (assuming that recently used pages will be used again in the near future) and keeps these pages in RAM if possible. If the program has a good "locality of reference" this assumtion will be true and Linux prediction algorithm will work. Holding a working set in main memory does only work if there is enough main memory. If you have too many processes running on a machine, the kernel is forced to put pages on disk that it will reference again in the very near future (forcing a page-out of a page from another working set and then a page-in of the page referenced). Usually this results in a very heavy increase in paging activity and in a sustantial drop of performance. A machine in this state is said to be "thrashing". On a thrashing machine the processes are essentially running from disk and not from RAM. Expect performance to drop by approximately the ratio between memory access speed and disk access speed. A very old rule of thumb in the days of the PDP and the Vax was that the size of the working set of a program is about 25% of its virtual size. Thus it is probably useless to provide more swap than three times your RAM. But keep in mind that this is just a rule of thumb. It is easily possible to create scenarios where programs have extremely large or extremely small working sets. For example, a simulation program with a large data set that is accessed in a very random fashion would have almost no noticeable locality of reference in its data segment, so its working set would be quite large. On the other hand, an xv with many simultaneously opened JPEGs, all but one iconified, would have a very large data segment. But image transformations are all done on one single image, most of the memory occupied by xv is never touched. The same is true for an editor with many editor windows where only one window is being modified at a time. These programs have - if they are designed properly - a very high locality of reference and large parts of them can be kept swapped out without too severe performance impact. One could suspect that the 25% number from the age of the command line is no longer true for modern GUI programs editing multiple documents, but I know of no newer papers that try to verify these numbers. 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?). WHERE SHOULD I PUT MY SWAP SPACE? ================================= 1. Mechanics are slow, electronics are fast. Modern hard disks have many heads. Switching between heads of the same track is fast, since it is purely electronic. Switching between tracks is slow, since it involves moving real world matter. So if you have a disk with many heads and one with less heads and both are identical in other parameters, the disk with many heads will be faster. Splitting swap and putting it on both disks will be even faster, though. 2. Older disks have the same number of sectors on all tracks. With this disks it will be fastest to put your swap in the middle of the disks, assuming that your disk head will move from a random track towards the swap area. 3. Of course your disk head will not move randomly. If you have swap space in the middle of a disk between a constantly busy home partition and an almost unused archive partition, you would be better of if your swap were in the middle of the home partition for even shorter head movements. You would be even better off, if you had your swap on another otherwise unused disk, though. 4. Newer disks use ZBR (zone bit recording). They have more sectors on the outer tracks. With a constant number of rpms, this yields a far greater performance on the outer tracks than on the inner ones. Put your swap on the fast tracks. 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. HOW SHOULD I PARTITION MY DISK? =============================== 1. 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 "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/spool/news there are about 12000 files on / and abou 44000 files on news. 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). Noncontigous 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 filesystems. ext2 has several strategies to avoid external fragmentation. ext2 does not force you to choose large blocks for large file systems (except for very large filesystems in the 0.5 TB range 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. 2. Files have lifetimes. After a file has been created, it will remain some time on the system and them be removed. File lifetime varies greatly throughout the system and is partly dependent on the pathname of the file. For example, files in /bin, /sbin, /usr/sbin, /usr/bin and similar directories are likely to have a very long lifetime: many months and above. Files in /home are likely to have a medium lifetime: several weeks or so. File in /var are usually short lived: Almost no file in /var/spool/news will remain longer than a few days, files in /var/spool/lpd measure their lifetime in minutes or less. 3. 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 exspect 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 that backup costs for virtually everyone! 4. 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 / or /home partition. A common model creates /, /home and /var partitions as discussed above. This is simple to install and maintain and differentiates well enough to avoid adverse effects from different lifetimes. It fits well into a backup model, too: Almost noone bothers to backup USENET news spools and only some files in /var are worth backing up (/var/spool/mail comes to mind). On the other hand, / changes infrequently and can be backup up on demand (after configuration changes) and is small enough to fit on most modern backup media as a full backup (plan 250 to 500 MB depending on the amount of installed software). /home contains valuable user data and should be backup up daily. Some installations have very large /homes and must use incremental backups. Some systems put /tmp onto a seperate partition as well, others symlink it to /var/tmp to achieve the same effect (note that this can affect single user mode, where /var will be unavailable and the system will have no /tmp until you create one or mount /var manually) or put it onto a RAM disk (Solaris does this for example). This keeps /tmp out of /, a good idea. This model is convenient for upgrades or reinstallations as well: Save your configuration files (or the entire /etc) to some /home directory, scrap your /, reinstall and fetch the old configurations from the save directory on /home.