It is generally believed to be a "rule" of cluster size selection that
"smaller is better". As FAT16 partitions have gotten larger and slack waste has gone through the roof, the push
toward using FAT32 to reduce cluster sizes has been tremendous. While FAT32 does allow the
use of larger hard disks and greatly reduced cluster sizes, there is an important
performance consideration in using FAT32 that is not often talked about.
Let's consider a partition that is just under 2,048 MB, the largest that FAT16 can
support. If this partition is set up under FAT16, it will result in a file allocation
table with 65,526 clusters in it, with each cluster taking up 32 KB of disk space. The
large cluster size will indeed result in a great deal of wasted space on the disk in most
cases. Therefore, often it will be recommended that FAT32 be used on this volume, which
will result in the cluster size being knocked down from 32 KB to 4 KB. This will, in fact,
reduce slack on the disk by an enormous amount, often close to 90%, and potentially free
hundreds of megabytes of previously wasted disk space.
However, there is another side to this; you don't get this reduced cluster size for
free. Since each cluster is smaller, there have to be more of them to cover the same
amount of disk. So instead of 65,526 clusters, we will now have 524,208. Further more, the
FAT entries in FAT32 are 32 bits wide (4 bytes), as opposed to FAT16's 16-bit entries (2
bytes each). The end result is that the size of the FAT is 16 times larger for FAT32 than
it is for FAT16! The following table summarizes:
FAT Type |
FAT16 |
FAT32 |
Cluster Size |
32 KB |
4 KB |
Number of FAT Entries |
65,526 |
524,208 |
Size of FAT |
~ 128 KB |
~ 2 MB |
Still worse, if we increase the size of the FAT32 volume from 2 GB in size to 8 GB, the
size of the FAT increases from around 2 MB to a rather hefty 8 MB. The significance of
this is not the fact that the FAT32 volume will have to waste several megabytes of space
on the disk to hold the FAT (after all, it is saving far more space than that by reducing
slack a great deal). The real problem is that the FAT is referred to a lot during
normal use of the disk, since it holds all the cluster pointers for every file in the
volume. Having the FAT greatly increase in size can negatively impact system speed.
Virtually every system employs disk caching to
hold in memory disk structures that are frequently accessed, like the FAT. The disk cache
employs part of main memory to hold disk information that is needed regularly, to save
having to read it from the disk each time (which is very slow compared to the memory).
When the FAT is small, like the 128 KB FAT used for FAT16, the entire FAT can be held in
memory easily, and any time we need to look up something in the FAT it is there at our
"fingertips". When the table increases in size to 8 MB for example, the system
is forced to choose between two unsavory alternatives: either use up a large amount of
memory to hold the FAT, or don't hold it in memory.
For this reason, it is important to limit the size of the file allocation table to a
reasonably-sized number. In fact, in most cases it is a matter of finding a balance
between cluster size and FAT size. A good illustration of this is the cluster size
selections made by FAT32 itself. Since FAT32 can handle around 268 million maximum
clusters, the 4 KB cluster size is technically able to support a disk volume 1 TB (1,024
GB) in size. The small problem here is that the FAT size would be over 1 GB! (268 million
times 4 bytes per entry).
For this reason, FAT32 only uses 4 KB clusters for volumes up to 8 GB in size, and then
quickly "upshifts" to larger clusters, as this table shows:
Cluster Size |
"Minimum"
Partition Size (binary MB) |
"Maximum"
Partition Size (binary MB) |
4 KB |
0.5 GB |
8 GB |
8 KB |
8 GB |
16 GB |
16 KB |
16 GB |
32 GB |
32 KB |
32 GB |
64 GB? |
Note: I don't know what
Microsoft plans to do at 64 GB. They could decide to go to 64 KB clusters, or just leave
the clusters at 32 KB and let the FAT size increase linearly as the disk size increases
from there.
As you can see, despite the claims that FAT32 would solve large cluster problems for a
long time, it really doesn't. As soon as you hit 32 GB partitions, you are back to the
dreaded 32 KB we all knew and hated in FAT16. Obviously 32 GB is a lot better than having
this happen at 1 GB, of course, but still, FAT32 is more of a temporary solution than a
permanent one. If you're saying to yourself "Yeah, but 32 GB is huge. I'll
never have a disk that large and even if I do, I won't care about a little wasted disk
space", then remember that people said the same thing about 2 GB hard disks only a
few years ago, and some people today now call 2 GB disks "small"!
The table below is a little exercise I did for fun, to show the size of the FAT (in MB)
as the partition size increases, for various cluster sizes. You can see why FAT32 doesn't
stick with 4 KB clusters for very long--if it did, you'd need enormous amounts of memory
just to hold the table. The entries in bold show what FAT32 will choose for a partition of
the given size; by going up in cluster size Microsoft keeps the size of the FAT to no more
than about 8 MB:
Partition Size |
4 KB Clusters |
8 KB Clusters |
16 KB Clusters |
32 KB Clusters |
8 GB |
8 MB |
4 MB |
2 MB |
1 MB |
16 GB |
16 MB |
8 MB |
4 MB |
2 MB |
32 GB |
32 MB |
16 MB |
8 MB |
4 MB |
64 GB |
64 MB |
32 MB |
16 MB |
8 MB |
2 TB (2,048 GB) |
-- |
1,024 MB |
512 MB |
256 MB |
The last entry, 2 TB, is for fun, to show how laughable I find it when people go on
about 2 TB hard disks being supported by FAT32. Technically they are, I guess, if you want
to deal with a FAT that is 256 MB in size and go back to having 40% of your disk wasted by
slack. We had better hope our system memory goes up by a factor of 1,000 before our hard
disks do again. (Really, what this all shows is the FAT file system is stretched beyond
its limits even with FAT32. To get both good performance and disk space efficiency for
very large volumes requires a clean break with the past and the use of a high performance
file system like NTFS.)
Next: Using Partitioning with Hard Disks Over 2 GB
