Studying for the A+, Network+ or Security+ exams? Get over 2,600 pages of FREE study guides at CertiGuide.com!|
Join the PC homebuilding revolution! Read the all-new, FREE 200-page online guide: How to Build Your Own PC!
NOTE: Using robot software to mass-download the site degrades the server and is prohibited. See here for more.
Find The PC Guide helpful? Please consider a donation to The PC Guide Tip Jar. Visa/MC/Paypal accepted.
|Take a virtual vacation any time at DesktopScenes.com - view my art photos online for FREE in either Flash or HTML!|
Tired of the boss? Ever wanted to be an independent freelancer? Not sure how to get started?
The all-new Online Freelancing Guide can help. Tons of useful info, and it's free! Join the online freelancing revolution today.
Using Partitioning to Reduce Slack
Since slack is dependent on the cluster size used for the partition, and the cluster size is directly linked to partition size, it is possible to dramatically improve the storage efficiency of the hard disk simply by dividing it into multiple partitions. The larger the current partitions are, and the more files on the disk, the greater the opportunity for improvement. This applies both to FAT16 and FAT32 partitions--on older systems that use FAT16 partitions for volumes over 512 MiB, cluster sizes will be 16 kiB or 32 kiB, and slack will be significant, and the same goes for FAT32 partitions that are 16 GiB or more.
Let's take the example of a 2 GB disk (usually called a 2.1 GB disk by hard disk manufacturers, since they talk in decimal gigabytes). Let's say that we have 24,000 files on our disk and each has an average amount of slack amounting to 60% of a cluster. Now consider various partitioning alternatives; we can either keep the disk in one piece or break it into smaller pieces. Here is the impact on (approximate) slack space:
As you can see, putting a 2 GB disk in a single partition is inefficient; typically 20% or more of the disk is going to be wasted, and you can cut that basically in half just by going to a pair of partitions. You can cut it much further by dividing the disk further. In fact, the best solution might seem to be just going to 128 MiB partitions, which drops slack down to a very small number. There's only one problem with this: you have to use 16 partitions! Do you really want your files spread over 16 disk volumes, from C: to R:? Most people don't. (I cringe at the very thought. :^) )
With a larger disk and FAT32, the example is not that much different, but the slack depends entirely on how many more files you put on that larger disk. If you put the same number of files on the larger disk using FAT32, slack (as a percentage of disk space) decreases dramatically; if you put many more files on the larger partitions then you "give back" some of the slack savings, though of course you are still ahead of where you would have been using FAT16. Which of these is most appropriate depends on how you are using your system. In many cases, the large hard disks available today are used to hold big files, such as video and audio, that were rarely seen on older PCs. In other applications, a bigger disk just means many more small files.
Let's look at an example where have, say, a mythical 64 GiB (68.7 GB) hard disk and 96,000 files on it. Here, I am looking at a disk 32 times the size of the previous example, but have only increased the number of files by a factor of four. This means slack, as a percentage, will be lower even for partitions of the same cluster size. Here's how this looks under FAT32, assuming the same 60% end cluster waste:
As you can see, the total amount of slack, in bytes, is higher, because we have more files. However, the percentage of total disk space used up in slack is much lower because the disk is so much bigger--that's the advantage of FAT32. As before, when you increase the cluster size, you end up with bigger partitions, and more slack. 32 kiB clusters means four times as much slack as 8 kiB clusters. However, with the total slack still so low--2.8%--and with the huge size of the disk being contemplated (64 GB) the entire matter is of arguable importance. On a 2 GB disk, 450 MB is a big deal; on a 64 GB disk, 1.8 GB really is not, at least to most people. While most people wouldn't put an entire 64 GB hard disk in one partition (there are other reasons to avoid doing this, not just slack), it just isn't the big deal it used to be.
The examples above show that there is a tradeoff between saving slack and causing your disk to be broken into a large number of small pieces. Which option makes the most sense for you depends entirely on what you are doing with your disk, and on your personal preferences. I cannot stand having my disk chopped into little bits; on an older (FAT16) system I usually use 8 kiB or 16 kiB cluster-size partitions and sacrifice some more storage for the sake of what I consider "order". Others prefer the use of more, smaller partitions. You should also bear in mind the space tradeoff in using multiple partitions, something the "partitioning fanatics" (my pet name for people that like to chop a 1 GB disk into eight 128 MB partitions) often don't realize.
On a FAT32 system with a large hard disk, I usually go with partitions no more than 16 GiB, sticking to 16 kiB clusters. The difference between 8 kiB and 16 kiB clusters is not significant enough to warrant all the volumes needed to divide a very large disk into 8 GiB units, in my estimation. On some disks, such as backup volumes or ones where I will be storing large multimedia files, I will use 32 kiB clusters and very large volumes. This is an example of tailoring one's partition size and cluster size to the type of data being stored on the partition. If the files being put on the volume are very big, the cluster size becomes essentially irrelevant.