The FAT file system used by DOS and Windows divides all of the file data on the hard
disk into clusters comprised of multiple sectors. A cluster is normally between 2 kiB and 32 kiB in size, in powers of two, containing between 4 and 64 sectors of user data. This is done to make managing the location of data easier. Clusters and related file system structures are discussed here.
The choice of cluster size has an impact on real-world performance, though for
most people it is not all that significant. In a nutshell, larger clusters waste more space due to slack but
generally provide for slightly better performance because there will be less fragmentation and more of the file will be in
consecutive blocks. This occurs because when clusters are larger, fewer of them are needed
than when they are small. A 10,000 byte file would require three 4 kiB clusters but only
one 16 kiB cluster. This means this file will always be in a contiguous block if stored in
a 16 kiB cluster, but could be fragmented if stored in a 4 kiB cluster size partition.
(The slack tradeoff is a waste of 4 kiB more storage in the case of the 16 kiB clusters.)
Small cluster sizes also have a negative effect on partition because they require larger
file allocation tables, to manage their much larger numbers of clusters. These tradeoffs are discussed in detail here.
Traditionally, most people have tried to use cluster sizes as small as possible in
order to reduce slack and make more efficient use of disk space. This is of course a valid
goal, but it has become increasingly irrelevant today as hard disks approach truly
gargantuan sizes and the price per GB of storage drops to amazingly low levels.
Today, the large file allocation tables resulting from enormous FAT32 partitions means
that balancing slack reduction with performance effects is also important, unless you are
on a very tight budget. I certainly can't recommend forcing Windows to use 4 kiB clusters
on a 30 GB partition "to reduce slack" as some people do, because I personally
wouldn't want to take the performance hit of having 30 MiB file allocation tables--and I
wouldn't want to have to wait for that puppy to defragment either! 
Next: Volume Free Space
