Edit Article: Partition Planning Tips

Documentation[edit]

If an extended news item, enter info here:

Have you noticed how many new filesystems are now available for Linux these days? Not only ReiserFS, but also SGI's XFS and IBM's own JFS (in source form) are now available for Linux. What an incredible selection! And, of course, we also have the Coda filesystem as well as good old ext2, ext3 and ext4. As usual, choice is an excellent thing. In this collection of tips, we'll be looking at another area where we have lots of freedom -- how to organize partitions on disk. Regardless of which new-fangled filesystem you are using, good partition layout is essential. Here are three tips that will help to keep things organized. == Don't partition the entire drive == These days, new machines often have 1 terabyte or more of storage on a single drive. These drives are great, but they create a new problem: how exactly do you partition these things? Many of us can only conceive of filling up 250 GB, and that's if we actually tried to fill things up. Instead of partitioning the entire drive during installation, you may want to consider partitioning only the portion of the drive that you know you will actually use. Later, when you've figured out how to use the 750 GB of free space sitting at the end of your drive, you'll have a better idea of how to partition it. Then, you can fire up fdisk or cfdisk and create a partition that meets your exact needs. For now, create partitions that are large enough to hold your current files, plus allow for future growth. Don't worry, the free space at the end of your drive will still be there when you need it. Another possibility is to use LVM to create a large pool of storage, but create logical volumes for filesystems only as you need them. See [[LVM Fun]] and [[LVM Install Guide]] for more information on how to use LVM. == Partition for backups == My second organizational tip will help your backups go more smoothly. If you are going to regularly back up a portion of your file system tree, it's a very good idea to place this data on a separate file systems. Why? Because many copying and archiving tools have a special option for not crossing partition boundaries (such as cp's -x option), which will make it easy to select only the files you want. Also, you can select a size for the filesystem so that it is close to capacity of your backup media. That way, you'll never have to worry about filling up a tape, and you can monitor how close you are to filling up your backup media by using the df command to see how much space is left on that particular filesystem. Then, you can track your storage and backup needs and plan accordingly. == Partition to reduce fragmentation == File fragmentation occurs when there is not enough contiguous space on a filesystem to store an entire file. The result? The file is broken into non-contiguous "fragments," which are stored on disk. When this file is accessed, the hard drive's head needs to jump all over the place to read in the entire file. This slows down I/O, adding additional seeks to the reading process. OK, you may ask, what's the big deal? After all, ext4 filesystems take a long time to exhibit performance degradation due to fragmentation. However, I would argue that fragmentation can still be a problem, because although ext4 does not get fragmented easily, fragmentation is a one-way, cumulative process. That is, while ext4 fragments slowly, it cannot defragment itself. In other words, any often-modified ext4 filesystem will gradually get more and more fragmented, and thus slower. Even worse, there are no production-quality online ext4 filesystem defragmenting programs currently available. This means that fragmentation is guaranteed to get worse over time. That's a pretty involved and time-consuming process. So, how can the problem of fragmentation be dramatically reduced and contained? I'll cover all the juicy details in my next tip. See you then!

Save page Show preview Show changes Cancel