Well, cluster size is (and always has been and always will be) a trade-off.
http://www.pcguide.c...artFAT32-c.html
Quote
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 kiB 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 MiB 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 kiB cluster size is technically able to support a disk volume 1 TiB (1,024 GiB) in size. The little problem here is that the FAT size would be astronomical--over 1 GB! (268 million times 4 bytes per entry).
If you want an efficient (actually as efficient as it can be) FAT filesystem, you want SMALL FAT tables, please read as FEW clusters indexed in them, i.e. LARGE cluster size.
The amount of "wasted" space with large cluster size will however be impressive.
The "default" setting is 32 Kb cluster size (and is ALREADY NOT efficient on such Large volumes).
The previous 16K size could be defined as "pure folly".
A FAT 32 volume is made by:
- a few "hidden sectors", number may vary in different implementations, but usually32 sectors
- a FAT table
- a second copy of it
- indexed space containing files or ready to contain them
Since evey FAT table entry is 4 bytes long, every sector (exception made for the first one, that "loses" two entries) of a FAT32 table can index 512/4=128 clusters
Talking of a 681GB partition, i.e. 681*1024*1024*1024=731,218,182,144 bytes one, in sectors 731,218,182,144/512= 1,428,160,512 you have
around:
32+2*348,502+ 1,427,463,476=1428160512
I.e. the FAT table is around 348,502*512=178,433,024 bytes in size or around 170 Mb!
Using 64 Kb cluster size, the FAT becomes a much better (though still "crazy") roughly 42 Mb.
The default according to MS is 32 Kb clusterss for anything bigger than 32 GB, meaning that according to them, a (say) 33 Gb partition with 16 Kb clusters, i.e. with a FAT table of around 8Mb, is already less efficient than a 32 K one and you had a partition 20 times bigger with half the size for clusters, a 1 to 40 ratio!
Spring effect graphics!
http://reboot.pro/13466/
jaclaz
Frontpage
Forums
Tutorials
Members
Calendar
Subscription
Donate
Links
Contact 
Help
Back to top
:
, and I avoided it (most probably since long before you "fixed it") by simply not making multiple primary FAT partitions 
