Takeaway: Linux partition management needlessly strikes fear in the hearts of many system admins. In this Daily Drill Down, Vincent Danen unveils the mysteries behind this highly flexible partition management system.
New army recruits have to conquer the obstacle course, new lawyers have to pass the bar exam, and new Linux system admins have to demystify partition management. Overcoming such hurdles isn’t only good for your psyche, but, in the case of Linux partitions, it’s a boon for your network as well. Linux newbies aren’t the only admins struggling with partitions, however; there are plenty of Linux pros that aren’t getting the most from their partitions either, which is unfortunate to say the least. When you have a system as flexible and efficient as Linux partition management is, it would be a crime not to fully utilize it.
With other DOS-similar operating systems, such as Windows and OS/2, partition management is relatively simple to use. For more advanced file systems of this ilk, an entire disk is often dedicated as a C: drive, with additional physical drives being designated to other drive letters as needed. By choosing not to use FAT partitions, administrators can designate extremely large NTFS or HPFS partitions without wasting too much space.
With UNIX-based operating systems, however, the rules change. There are no drive letters, but mount points instead. To put it into Windows-speak, you can look at the entire system as being one large C: drive that can span multiple disks. The little ground you give in terms of simplicity, you more than make up for in terms of flexibility.
In this Daily Drill Down, I will explain how to establish a solid partition strategy for your UNIX-based system. In the process, I’ll also shed light on some of the more puzzling elements of Linux partitions, such as formats and partition names.
Partition strategies
In the “old” days, UNIX-based systems were usually given many smaller partitions, such as the root file system, /usr, /usr/local, /opt, /boot, /var, and even /tmp. Each of these used to be a separate mount point on separate file systems. The thinking behind this setup was that if a file system got corrupted, it would not affect the entire system. For instance, if /tmp got corrupted, it would be a relatively easy operation to reformat it without affecting the rest of the system. Another reason for this setup was that if an errant program attempted to fill up the file system, it would only fill up one small partition as opposed to a large partition that contained the entire system. Finally, this partition method could take advantage of older small hard drives by placing smaller file systems on them while saving more space on the larger drives for larger files.
While these concerns may still be valid for some, the preferred method for partition management these days seems to be to have as few partitions as possible. One reason for this larger partition scheme is that as a partition fills up, performance degradation becomes quite noticeable. For example, if you were to have a smaller size /var partition (where log files are stored) and a particular application were to create a rather large log, the /var partition could fill up and your server might come to a grinding halt. To this end, people will likely create a maximum of three partitions: the root file system, the swap partition, and a separate partition for /home.
Of course, in order to choose the most effective partition management strategy, you need to take into account how the system will be used. If the system is a workstation or home computer, using the three-partition method might be appropriate. On a server system, however, three partitions would most certainly undermine your system’s potential. You must also consider certain mount options, such as mounting a partition as read-only, noexec, and so on.
Once you consider all the options, you might find, as I have, that while both methodologies have their advantages and drawbacks, a mix of the two can be very advantageous.
Types of installations
Let's look at two simple scenarios to get an idea of what types of things you need to consider when planning a partition management strategy. The first scenario will be a workstation installation, and the second will be a server installation.
Workstation
Let's assume for a moment you are installing Linux as a workstation or home computer. The system contains a single 20-GB hard drive, which is not at all unreasonable with hard-drive prices being so low. Let's also assume that the system has 128 MB of RAM, which is important to know when determining the size of your swap partition.
With a 20-GB drive, you would probably want to allocate about 3 GB or 4 GB for the root file system to contain your entire Linux installation. This, of course, depends on the number of applications you plan on installing, the base install size of your chosen distribution, and so on. Some distributions, such as Debian, have a much smaller install base size than distributions like Mandrake Linux. Regardless, 3 GB or a little more is a good size in terms of the function for this computer and the size of the disk.
With 128 MB of RAM, you will need some swap space. The swap partition is where the Linux kernel will write information that is not often used and would normally reside in RAM. Because RAM is much faster to access than a hard drive, swap partitions should not be considered a substitute for RAM. For example, a system with 128 MB of physical RAM and a 1-GB swap partition will slow your system down because a lot of information will be swapped to disk and will be slower to retrieve. The general rule of thumb for swap partition sizes has been to create a swap partition equivalent to the amount of physical RAM installed on the system, so in this case you would want a 128-MB swap partition. For lower amounts of RAM, however, you could double the size. In this case you could use two 128-MB swap partitions or a single 256-MB swap partition. Going beyond twice the size of your physical RAM generally is not a good idea because it is usually a waste of space. If you have 256 MB of RAM plus a 256-MB swap partition, you’re looking at 612 MB of space available for writing. With too much swap space, the kernel could begin writing far too much information into that swap space and start slowing down your system. As well, if you have a large amount of RAM, like 1 GB, having a 1-GB swap partition is equally unreasonable. A good rule of thumb is to have no more than 256 MB of swap on any system, regardless of the amount of physical RAM installed.
So now we've used up roughly 3.5 GB of your hard drive, leaving another 16.5 GB available. I would allocate this to the /home partition, which is where all user information, personal files, and so on is stored.
Server
The partitioning scenario above would not be recommended for a server system. With a 20-GB hard drive, the partitions would be much different, and even the type of server would determine the size of partitions. For instance, if you plan on running a Web server, you will have to decide where Web pages will be stored. If you intend to follow the FHS, this will be in /var/www, or if you choose to use the more familiar /home/httpd, you will need to modify your partitions accordingly. In this case, you will need to decide if /var needs to be a larger partition or if /home should be the larger of the two.
Let's assume you have the same 20-GB drive mentioned above, but with 512 MB of physical RAM. Let's also assume the system will be a Web server and that Web pages will be in /home/httpd. In this situation, I would recommend a smaller root file system because servers generally do not run large programs such as GNOME or KDE, which take up large amounts of space. With this server, I would recommend a root file system of 2 GB, with a swap partition of 256 MB (half the size of the physical RAM; again to prevent the kernel from swapping too much to disk). /usr/local is a good mount point; it is a great place to store user-installed programs that do not come with the distribution. Giving /usr/local a size of about 2 GB is reasonable.
Putting /var on its own partition also makes sense here. If log files get too big, they won't fill up the root file system and prevent other parts of the system from working. To give the system plenty of room to store log files, spool files, and other variable data, a/var partition of about 1 GB is adequate. It may also be prudent to have another minimal installation of your chosen Linux distribution on its own partition as well. This way, if something happens with your primary OS, you can boot into the emergency install to perform maintenance. A 500-MB partition, perhaps mounted as /mnt/rescue,would suffice. Finally, you may want to place /tmp on its own partition as well, to prevent temporary files from filling up your system. By having /tmp as its own partition, you can also mount it as noexec, which is an extra security precaution that doesn’t allow any programs to be executed from the /tmp file system. A size of 500 MB should be appropriate for /tmp.
So now you've got about 15.5 GB of free space. Because your Web pages will be served from /home, allocating the rest of the free space to the /home partition makes sense.
Formats
Because there are a number of different file systems formats that are now available for Linux (such as the traditional ext2 and journaling file systems like ReiserFS, XFS, ext3, etc.), you may decide to mix and match file systems as your needs require. For instance, you may decide to use ReiserFS for all partitions except the /home partition because you want to enable quotas for users, so you may choose XFS, ext3, or ext2 to enable quotas. Or you may choose to have /tmp as ext2 and everything else as XFS.
In some instances, you may require a particular file system format for a particular partition. For instance, the qmail MTA is typically installed to /var/qmail because its queue has had problems on ReiserFS file systems. So if you want to use ReiserFS, and still use qmail, you may decide to use ReiserFS everywhere except for the /var partition, which would be formatted to ext2. It is this kind of versatility that separates the Linux partition management system from the rest of the pack.
Understanding partition names
In addition to their confusion over partition strategies, Linux newbies often struggle to make sense of partition names. Using names such as /dev/hdf4 and /dev/hdb can take some getting used to. Here is a good overview to help clarify the naming procedure.
Hard drives are associated by device entries. /dev/hdX (note the “h”) designates an IDE hard drive, whereas /dev/sdX (note the “s”) designates a SCSI hard drive. The last letter determines the drive itself. /dev/hda is the first IDE drive on the first IDE channel, while/dev/hdb is the second drive on the first channel. hdc and hdd are the first and second IDE drives on the second IDE channel. With ATA100 and ATA133 drives, you may have devices named /dev/hde, hdf, hdg, and hdh. These represent the first and second drive on the first ATA100 controller channel and the first and second drive on the second ATA100 controller channel, respectively. For SCSI drives, the names run up the alphabet: /dev/sda is the first SCSI drive, /dev/sdb the second, and so forth.
Some partition names also feature a number after the device, which represents the partition number. /dev/hdb2 is the second partition on the second IDE drive of the first IDE channel. With Linux, you can have four primary partitions and as many extended partitions as you like.
When determining where to put your partitions, it is a good rule of thumb to have the root file system (/) be the first partition (i.e., /dev/hda1), the swap partition be the second partition (i.e., /dev/hda2), and from there you can put partitions wherever you like. You may decide to put /var as hda3, /home as hda5, /usr/local as hda6, and so on. The partition numbers of 5 and higher (i.e., hda5) are extended partitions, whereas the partition numbers 4 and lower are primary partitions.
Conclusion
This basic introduction to partition management and strategies can't possibly cover every scenario. The size and disposition of partitions depends on what the computer is going to be used for, the size and number of drives available to Linux, and any number of other factors. Hopefully, by reading through these basic guidelines, however, you now have a clearer view of what the partition management structure should be on your particular network. Over time and with practice, you will be able to determine if a partition is too large and wasting space or too small and requiring more space. With every Linux installation, upgrade, and reinstall, you will continue to fine-tune your partition strategies, which will eventually provide you with the expertise to take full advantage of this incredibly efficient and flexible Linux system.
