CSUF LogoCSUF Site Navigation
optics.csufresno.edu

F9 Pre-Installation Tasks Partition Sizes

Department of Electrical and Computer Engineering
Assistant Professor Gregory R. Kriehn
Forums
Wiki
F9 Partition Sizes

If you need a primer about partitions, I suggest reading everything you can get your hands on. For starters, you may want to try reading an older article about partitions over at Linux Planet, but it is by no means complete, and by no means very specific. But it is a start.

As a point of reference, the first time I was set to install Linux on an x86 computer 
was to be on my fiancée's (now wife's) laptop using RedHat 7.0. She would use Windows whenever she needed the laptop, and I would use Linux, since I was in the midst of finishing my doctorate. So I popped in the RedHat CD, prepared myself to install Linux, and instantly got bogged down in trying to determine how much space I would need. What exactly is a partition again? How many partitions do I need? What is this 1024 cylinder limitation thingy? Primary partitions? Logical partitions? How much swap space? Does it make a difference? And so it continued for the next two days. I read everything I could find on the subject matter, starting with the RedHat 7.0 Documentation on Partitions (Appendix B) (which does provide an answer about that 1024 cylinder limitation thingy), but I still didn't feel like I had a lot of information to draw from regarding the exact number of partitions, why I needed them, and what sizes they should be. So now, after years of installing RedHat and Fedora Core on several different types of computers, I've developed more of a conceptual understanding and an empirical threshold for determining their relative sizes. Since there still doesn't seem to be a lot of useful information out there, or much justification for it, I'd like to provide some answers here.

In my opinion, there is a large misconception these days about Linux and partitions. I have read web site after web site stating that all you need is one (or at most two) partitions, in addition to a swap partition. This includes a / partition, the swap partition, and perhaps, if need be, a /home partition. Unfortunately, this point of view is overly simplistic
and is given as a stock answer to the world's problems (I believe), because not many people really know what the proper answer is anymore. Even RedHat now acknowledges the issue in their Enterprise documentation:

D.1.8. How Many Partitions?

At this point in the process of preparing to install Red Hat Enterprise Linux, you must give some consideration to the number and size of the partitions to be used by your new operating system. The question of "how many partitions" continues to spark debate within the Linux community and, without any end to the debate in sight, it is safe to say that there are probably as many partition layouts as there are people debating the issue.

LOL. How true it is. But let me give you my take on the subject.

First off, the problem with using only a / and swap partition... ...is exactly that. *Everything* is placed on a single partition. This includes all user data within /home, log information in /var, user-installed programs in /usr/local, etc. This tends to produce a security risk, because if your system is compromised, it will be compromised in its entirety. /tmp is typically world writable, for instance. And if you, say, have a runaway log process because something bad is happening on your system that you don't know about it, log files will be generated (sometimes at the rate of 1/sec) until your entire / partition is filled up, and the system crashes. Hard. The same could happen if old users are receiving 100+ spam e-mails a day in /var/spool/mail and no one is cleaning them out (or has turned off the accounts). And what happens if you want to upgrade to a more recent Linux distribution? If you perform a full re-install, your /home directory will be blown away, unless you completely backup all of your files first, which could be a pain. Ignorance may be bliss for the masses who do not understand these implications
— but reality will eventually come back and bite you in the butt.

Seeing the problem of a single partition, the 2 partition + swap camp states that all you need is / and /home so that if you reinstall the operating system, you don't necessarily have to reformat /home
thereby saving your data. But again, this still doesn't get around the problem of filling /var by accident, or considering the fact that user-installed programs are normally installed in /usr/local (etc). Wouldn't it be nice not to have to re-install these programs each time Fedora Core is upgraded (really, installed) to a new version by not having to reformat usr/local? In my opinion, the 2 partition + swap scheme is nearly as flawed as the 1 partition + swap scheme. And security is still a problem. The only reason to consider this partition layout as an option is if you are very, very tight on space on your hard disk. All of your free space will be spread only between / and /home, opposed to having other partitions that may be wasting it. But this clearly is not optimal. If you are that tight on space, it's time to start looking at purchasing a new hard drive.

Before I provide justification for partition numbers, types, and their sizes, I'd also like to clear up a common misconception about megabytes (MB) and gigabytes (GB). If you don't already know this (and most people do not) understand that if you want to create a 1.0 GB partition, you do not reserve 1000 MB. We are taking bits and bytes here, which means powers of two. 210 bytes = 1024 bytes, not 1000. And even so, stating that 1024 MB is equal to 1 GB is (kind of) a misconception, because a "true" gigabyte would be 29 bytes only be 512 MB in size. But convention states that 1024 MB = 1.0 GB. A similar rule holds true for the relationship between gigabytes and terabytes. Call me your typical anal engineering professor.

So, how many partitions?


The answer I have developed to the never-ending partition question comes down to this, at least for Fedora 9:

Server Partition Sizes
Partition Name Size (MB) Size (GB)
/boot 128 0.125
/ 1024 1.0
/opt 2048 2.0
/tmp 5120 5.0
/usr 15360 15.0
/usr/local 5120 5.0
/var 20480 20.0
swap 2048 2.0
/backup 25600 25.0
/home 25600 25.0

You will notice that things have changed a bit since Fedora 8. I am finding that my server is seeing heavier and heavier use, and I am having difficulty with my /var partition filling up (Web Server, Kriehn Repository, etc.), so I decided it was time to adjust things a bit. If you have a 120 GB hard drive, the remaining 20 GB can be used for a Windows partition.

I've also softened my stance a bit with respect to laptop use, and suggest the following:

Simple Laptop Partition Sizes (No Server Applications)
Partition Name Size (MB) Size (GB)
/ 20480 20.0
swap 2048 2.0
/backup 25600 25.0
/home 25600 25.0

If you have a 120 GB hard drive, the remaining 50 GB can be used for a Windows Partition.

ext3 Adjustments


Unfortunately, even these tables are not quite accurate. If you are using the ext3 filesystem, it automatically uses a portion of a given partition for journaling, which allows for a graceful recovery in the event of a crash (opposed to corrupting the filesystem, which is very, very bad). The only problem is that the journal chews up part of the partition, so the effective size of the partition actually shrinks. In fact, df (the program used to report file system disk space usage), does not even acknowledge this space in the first place. Empirically, I find that the partition sizes require, roughly, an additional 3.25% to provide you with the "desired" size when using ext3 with its default journal-size. So, when creating partitions in PartitionMagic, if I want to create a 2.0 GB partition, I will create one that is about 1024 MB * 2 * 1.0325 = 2114.56 MB in size. I will then allow PartitionMagic to tweak the actual size of the partition, since partitions like to be rounded to the nearest cylinder on the hard drive. For instance, it is not possible to create a 128 MB * 1.0325 = 132.16 MB partition, but it is possible to create a 133.32 MB partition (the closest allowable size), which will then be interpreted as 130 MB by df. That's close enough to 128 MB for me. Overly complicated? Maybe. But it's a nice rule of thumb to remember. And why use PartitionMagic??? See the Dual Boot Options page for another long-winded explanation.

At any rate, on to partition sizes and their justifications:

/boot


It is always good to have a /boot partition since this will isolate where the kernel and grub configuration files are located (I typically allow grub to be installed on the Master Boot Record). I like to make it a primary partition, if possible, and like to keep it reasonably small since its primary purpose is to hold kernel files such as config, initrd, vmlinuz, and System.map. It is also good to place the partition at the very front of the hard drive, since the BIOS in some older systems cannot access more than the first 1024 cylinders on a hard disk. Although this is not really an issue in newer motherboards, it still maintains good practice. /boot is not a partition that you want to be moving around, lest you enjoy making your system unbootable. 128 MB provides the system enough flexibility to allow for multiple kernels to be installed (including smp kernels, if need be), but small enough that you are not going to be wasting a lot of space.

/


Anything that is not directed to a separate partition will be placed in /, the root directory. This includes global executable files such as bash, dfecho, mkdir, ls, mv, tcsh, vi, etc. that are placed in /bin, and superuser files such as fdisk, fsck, ifconfig, init, restorecon, etc. that are placed in /sbin, along with files in several other directories. With the setup mentioned here, / will also contain root's home directory /root. If other partitions are setup properly, often times most (if not all) of the files and directories contained in / can be set to read-only as an added measure of security, if you are paranoid. Making / 1.0 GB gives yum the flexibility to install new programs and files (and perform updates) without running out of space, but still keeps it small since only about 300 MB or so will actually be needed otherwise. In prior versions of Fedora, I used to limit / to 512 MB, but I would often have to keep telling the system to remove old kernels because it needed additional space when updating certain packages. At 1.0 GB, I seem to have found a nice balance where this is no longer the case.

Starting with /, down through /backup, I tend to create new partitions as logical ones, since hard drives cannot handle more than 4 primary partitions total.

/opt


/opt, which stands for "optional", is the one partition that is a bit difficult to justify. However, there are programs that, although rare, like to be installed in /opt. If you do not want to re-install them each time you upgrade Fedora (if your choose to upgrade by re-installing the entire operating system), then creating /opt gives you the option of not having to re-format it and do exactly that. An example of a program that can be installed in /opt is the current implementation of Java, as discussed very nicely in Stanton Finley's FC5 Installation Notes. 2.0 GB keeps the partition small enough that you are not going to waste a lot of space if it remains largely unused, but does give you the flexibility having it available, just in case.

/tmp


The temporary directory /tmp, is typically created with world writable permissions since programs often need to create temporary files as they perform certain operations. (An example of this is when you download, say, a video file off the internet and use mplayer and mplayerplug-in to view it.) The drawback to /tmp is that it can potentially become a security hole (it is, after all, world writable). Therefore, I like to keep it as a separate partition, so that if I need to lock down parts of the system, it becomes much easier for me to do so. /tmp is also useful when you need to store a lot of information in a temporary location, such as when you are getting ready to burn CDs from ISO images. I create a 5.0 GB partition for /tmp since it allows me to store 1 DVD ISO image at a time (which can be up to 4 GB), and still have an additional gigabyte left over for other temporary files. /tmp, theoretically, can be made fairly small (256 - 512 MB'ish), but it is nice to have some extra space set aside if it's needed in a pinch.

/usr


/usr is where all user-level system-installed programs and packages are located. I also like to keep /usr separate from /usr/local, because /usr/local is the traditional place for user-installed packages, opposed to system-installed packages. /usr typically needs to be big, depending upon how many packages you choose to include when first installing Fedora, and depending on how many user-level system packages you plan on installing via yum after the initial installation is complete. I keep the partition at 15.0 GB to give me plenty of breathing room. Right now, exactly 7.0 GB of it is in use. When /usr is close to being full, I tend to get nervous.

/usr/local


As just mentioned, /usr/local is where all of the user-installed packages and programs are typically installed. For example, I like to compile mplayer by hand — /usr/local is where all the source files are located. I also use IDL, Interactive Data Language, which is also installed in /usr/local. Keeping /usr/local separate from /usr gives me the freedom of not having to reformat the partition if I upgrade to the most recent version of Fedora Core. This way, all I have to do is go into the directories and re-compile the programs, if necessary. If you plan on installing and compiling a lot of programs by hand, make /usr/local big. I currently have /usr/local set to 5.0 GB, and have about 4.0 GB free. Again, it's nice to have breathing room for future use.

/var


/var is where all of your various, miscellaneous files are stored, including log files, the mail spool, and downloaded rpm packages to be updated by yum. I used to keep /var at 2.0 GB, but have found that if yum has to update a lot of programs, it will quickly run out of space (/var/cache/yum is where the rpms are temporarily stored). This meant that I sometimes had to use yum to upgrade packages piece meal far from optimal. As of Fedora 9, I've upped the size to 20.0 GB, simply because my Web Server and Kriehn Repository (which both use /var) are starting to see heavy use. Keep an eye on the size of /var. If it suddenly blooms, it probably means that you either have a lot of old rpm packages floating around in /var/cache/yum, that people are spamming your users' mail accounts, or you have a runaway log process (which is indicative of a larger problem). The nice thing about keeping /var on a separate partition is that if something bad does happen and it fills (which is not as uncommon you might think), the operating system will not crash just complain a lot until you do something about it. The nature of /var is one of the strongest arguments for an expanded partitioning scheme for your Linux system.

swap


The generic rule of thumb for swap space is that it needs to be 2 times the size of your physical memory, although with the 2.6 kernel, I do not really believe this is still necessary. I've found that memory mapping, paging, and the general snappiness of the system has vastly improved over the older 2.4 kernel series due to a superior implementation of virtual memory and how it's handled (Linus and the kernel developers do seem to know what they are doing). As a result, the system rarely has to resort to using swap space these days, making the requirement for a large swap partition largely obsolete. Still, old habits are hard to break, and so I've set aside 2.0 GB for swap since I have 1.0 GB of memory (exactly 2048 MB in this case, since swap does not contain a journal). To be safe, I'd still make it at least the size of your current, physical memory. It would be good for someone to do some research on this almost all of the current information about Linux swap space is now outdated.

/backup


Although completely unnecessary, I find the creation of a /backup directory to be extremely useful. I use it to keep an hourly snapshot of my entire /home filesystem (using rsync) so that, at most, I lose an hour's worth of work. I also keep hourly, daily, weekly, and monthly snapshots of my system on a remote Linux RAID 5 server but even so, if the network is down, it is nice to have a local /backup partition. Since 25.0 GB is the size of /home, 25.0 GB is the size of /backup.

/home

The size of /home all depends upon how much data you have in your home directory, and how quickly it grows. I find that I require somewhere between 1 - 2 new gigabytes per year for all of my data, and with 15 GB of data already used, 25.0 GB it is for the partition. This gives me several years to grow, and still provides plenty of room for me to add new users to the system from my research group, if necessary. I have known some systems that have over 100 GB set aside for /home. It all depends upon the number of users, and their space requirements. I typically create /home as a primary partition, which means 3 primary partitions are used in total for Fedora 9. If you have a Windows partition, as I do, then that becomes the 4th.

Conclusion


There you have it. The optimal number of partitions for a Linux system with Server Applications (at the very least, for Fedora 9), is 10. These 10 partitions, /boot, /, /opt, /tmp, /usr, /usr/local, /var, swap, /backup, and /home will give you enough flexibility to keep the system fairly robust, and add some options for security, if necessary. For laptops, perhaps you can get away with 3. Create them however you like I like using PartitionMagic, although fdisk, Disk Druid, gparted, or qtparted can be used as well. See the Dual Boot Options page for further details.