When formatting a 64GB USB thumb drive to FAT32, you can select several different “allocation unit sizes”…
Default, 512, 1024, 2048, 4096, 8192, 16K, and 32K.
Because the thumb drive is a solid state drive and not a mechanical drive, I don’t see how changing those sizes would have much of an effect on access speed?
Is this correct?
Also I tried calling San Disk and asking what allocation unit size they format their 64GB thumb drive to at the factory and the guy did not have that answer in his notebook, so could not answer, and did not know what to do!
P.S. You of course CAN’T DO THIS ON WINDOWS 10! This is something a lot of people need, so of course Microsoft only allows exFAT formatting of USB drives and you must get a third party application to do what you need.
If you have a lot of small files, then setting the allocation size larger will probably result in a lot of wasted space on your drive. If you have a lot of large files, then the larger allocation size does make things more efficient since the operating system doesn’t have to do as many block changes and can just read in data in large sequential chunks.
With a thumb drive (or any kind of flash disk) you don’t have to wait for a mechanical disk head to reposition itself, so you’re on the right track there. However, there is still some overhead associated with changing to another block. So there is a bit of a performance hit, though it is nowhere near as big as the performance hit you get with a mechanical drive.
In all likelihood they probably format it to an allocation size of 4096 at the factory, as that tends to be a nice compromise for most files - not too big that you waste a lot of space and not so small that you are constantly switching to another block.
In all honesty, with the size of modern thumb drives, it’s not worth worrying about. There is a bit of a performance hit associated with accessing a different block, but not much. You can just leave it at the default and not worry about it.
Even with mechanical drives these days, there is so much data caching going on that it’s not that big of a deal there either.
The other theoretical consideration is that a FAT32 volume can contain, at most, 268,435,445allocation units. A 256-byte cluster would cap out at a maximum volume size just a skosh under your full 64 gigabyte volume (63.999997 kibibytes) but that’s a trivial loss – less than 1kbyte – and 256 doesn’t seem available in the list you give anyway.
If you’re going to put on a zillion tiny files, a smaller alloc factor (512B or 1kB) would be less space-wasting, but **engineer_comp_geek’s **suggestion of 4kB is probably a sound compromise. Tiny files are pretty rare in modern computing any more anyway.
ETA: Microsoft Knowledgebase article about default allocation units for various MS filesystems. For a 64GB FAT32 filesystem, default seems to be 32KB.
There are (at least) two block sizes here. (Because the layering of virtualised interfaces so common now, there could indeed be more.)
By there is the physical storage block size. This is pretty much fixed by the hardware design. For flash, these are units of storage (pages) that the flask memory is laid out with in terms of physical layout on the die, and are the atom of storage. The flash can only read or write this size of data. When the flash drive is built, it may be made up of more than one flash storage chip, and these may be set up to be accessed in different ways. The controller might gain speed by accesses the chips in parallel, and for it, the atom of storage would be the page size times the umber of chips. Or it may access the chips individually, and remain with the individual chip’s page size. High end flash controllers (ie not USB) contain caches, and this may afford them the ability to present a different externally visible page size again (as they can buffer the pages in the cache.) However the interface used may define a block size, and give everyone no choice.
Thus the operating system is presented with a physical block size by the storage device. Back in the days of spinning rust this was usually the same as the intrinsic block on the disk.
Then the file system needs to decide on its own unit of allocation. As described above, this is often a space/performance question. However the different dynamics of flash to disk operation can change the optimal point. Many file systems are journalled, and this changes things significantly. The cost of rewriting information when truncating the journal can be affected by the choice of file system block size. FAT otoh is not exactly sophisticated.
According to this reputable source (and some weblinks provided therein), changing the blocksize is highly likely to have a negative effect on access speed, as well as on the wear of your thumb drive. Avoid reformatting your thumb drive, keep it at factory default, just erase all that’s on it.
However, if you must, and you are on a Unix-like system, try that.