Indeks
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. 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 20 or 34 gigabytes 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 12 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 22 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.
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 partition. 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 this partition 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 partition. Then, you can track your storage and backup needs and plan accordingly.
Partition to reduce fragmentation
At the beginning of this article, I mentioned all the fancy new journaled filesystems now available for Linux. Amid all the excitement, it's easy to forget our old friend, the ext2 filesystem. ext2 does have some drawbacks; it is not extremely robust, for example. However, one thing it does excel at (especially when compared to Microsoft's NTFS) is keeping fragmentation to a minimum. If you don't know, 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, ext2 filesystems take a long time to exhibit signs of fragmentation. However, I would argue that fragmentation is still a big problem, because although ext2 does not get fragmented easily, fragmentation is a one-way, cumulative process. That is, while ext2 fragments slowly, it cannot defragment itself. In other words, any often-modified ext2 filesystem will gradually get more and more fragmented, and thus slower. Even worse, there are no production-quality ext2 filesystem defragmenting programs currently available. This means that fragmentation is guaranteed to get worse over time, and the only way to fix it is to wipe the filesystem clean, and restore all the original files from a backup. 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!
Don't partition the entire drive
These days, new machines often have 20 or 34 gigabytes 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 12 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 22 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.
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 partition. 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 this partition 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 partition. Then, you can track your storage and backup needs and plan accordingly.
Partition to reduce fragmentation
At the beginning of this article, I mentioned all the fancy new journaled filesystems now available for Linux. Amid all the excitement, it's easy to forget our old friend, the ext2 filesystem. ext2 does have some drawbacks; it is not extremely robust, for example. However, one thing it does excel at (especially when compared to Microsoft's NTFS) is keeping fragmentation to a minimum. If you don't know, 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, ext2 filesystems take a long time to exhibit signs of fragmentation. However, I would argue that fragmentation is still a big problem, because although ext2 does not get fragmented easily, fragmentation is a one-way, cumulative process. That is, while ext2 fragments slowly, it cannot defragment itself. In other words, any often-modified ext2 filesystem will gradually get more and more fragmented, and thus slower. Even worse, there are no production-quality ext2 filesystem defragmenting programs currently available. This means that fragmentation is guaranteed to get worse over time, and the only way to fix it is to wipe the filesystem clean, and restore all the original files from a backup. 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!
