For loading GC Games with USBLoaderGX via DiosMios/Nintendont, format your usb drive's primary partition as FAT32 with 32KB clusters (also known as blocks). This increases performance by reducing the NUMBER of transactions required to perform a read/write operation at the expense of the (very negligible) LENGTH of time to complete a transaction; since it's reading more data per transaction.
I'm not certain, since I can't find a GameCube disk specification, but I don't think the 32KB cluster size is an attempt to imitate the on-disk storage format of retail GameCube discs; which may or may not be 32KB. Retail Wii discs however, actually DO use 32KB clusters. As far as I can tell, 32KB is simply the highest density of bytes per cluster that is supported by FAT32 and of course, by extension, Wii homebrew storage libraries.
If you're concerned about storage efficiency and you're using extracted images, you can find the optimal cluster size by calculating the mode of file sizes and using that number rounded up to the nearest multiple.
mkdosfs -S 512 -s 64 -F 32 <partition>
Explanation:
Sectors contain bytes. -S 512 means that we're specifying 512 bytes per sector.
-S logical-sector-size
Specify the number of bytes per logical sector.
Clusters contain sectors. -s 64 means that we're specifying 64 sectors per cluster.
-s sectors-per-cluster
Specify the number of disk sectors per cluster.
If we represent this mathmatically:
512 bytes (per sector) * 64 sectors (per cluster) = 32KB clusters (32768 Bytes)
Or we can represent this visually:
sector[cluster[bytes], cluster[bytes], cluster[bytes], ... ]
This -F value represents how many bits are used in file allocation table entries. The entries themselves are used to address individual clusters on disk. As the number of bits increases for each individual FAT entry, the higher the value it's able to represent and the higher the quantity of file allocation table entries that it can address.
-F FAT-size
Specifies the type of file allocation tables used (12, 16 or 32 bit).
To restate this, the more bits you use for file allocation table entries, the larger the numbers they can store. The larger the numbers they can store, the more FAT entries you can have. The more FAT entries you can have, the more clusters they can point to. The more clusters you point to, the more bytes they can contain. The more bytes they can contain, the more data your disks can store using this system.
#...and this is about when I stared playing Super Smash Brothers instead of finishing this article
We specify 32bits for the allocation table entries so that they can store a maximum of 4,294,967,296 entries (aka FAT32). This gives us a approximate maximum disk size of 8TB... but 4 high order bits are reserved ... only 28 are used...
To further illustrate, a 32-bit value has 32 binary places(2^32). When all of the bits are set to 1, as in the binary representation of the number 4,294,967,296:
1111 1111 1111 1111 1111 1111 1111 1111
(spaces added for clarity)
On 32bit CPU architectures, this is the value of a unsigned integer.
unsigned int;
The datatype used in the FAT implementation is a signed integer which can store a maximum of 2,147,483,647 positive values represented in two's compliment form.