Windows 10 explorer shows incorrect USB drive size (DISKPART is OK)

I have a brand new Samsung 128 GB FIT flash drive that came formatted as exFAT. I reformatted it as FAT32 following the instructions on this page using the guiformat app referenced in the article:

https://www.howtogeek.com/316977/how...32-on-windows/

Now windows 10 explorer shows the drive as having a total capacity of only 53.6 GB. DISKPART shows the drive as having a single partition of 119 GB with no unallocated space. Partition Master similarly shows a single partition of 119.51 GB with no unallocated space. Windows Disk Management shows a single partition of 119.51 GB with no unallocated space in the lower pane, but only a 53.67 GB Capacity in Disk Management's drive listing in the top pane (see screenshot below). What is going on here? Why don't all of the applications agree on the USB drive size? Why are two different parts of the same application reporting two different size numbers for the same drive?

It works ok for me. What version of Win10 are you using? Did you use 32,768B allocation size?

PolarNettles said:

It works ok for me. What version of Win10 are you using? Did you use 32,768B allocation size?

version = 17134.407

The allocation size is 512. I chose the smallest setting possible based on this:

https://www.howtogeek.com/59435/ask-...taskbar-color/

which basically says there's no reason to not use the smallest setting on a flash drive given that the seek times are so low. Could that cause problems with Windows Explorer being able to read the correct drive size?

PolarNettles said:

With a 512B allocation size I see the same issue as you. This could just be a display bug but only Microsoft can confirm - you can report this issue in the Feedback Hub. To be safe you can use a larger allocation size.

512B may be more efficient depending on the page size of the NAND chips. But depending on what you're using the drive for, the cluster size might not have any noticeable performance impact.

Edit: I do see a potential problem. FAT32 uses 28 bits for cluster addressing, meaning you can have up to 268,435,456 clusters. With 512B clusters on a 128GB drive you would have very close to that number (minus some space for the FAT) - my drive has 246,151,166 clusters.

If you used a 27-bit integer you would only get 134,217,728 clusters. Meaning that if you tried to represent 246,151,166 in that 27-bit integer then you get 57,309,920,256, or 53.37GB. So there could be a bitwidth or signed/unsigned-conversion issue somewhere.

Interesting observation, that seems consistent with what I'm seeing. Just for the heck of it I tried formatting the drive with each of the available FAT32 Format Allocation unit size settings to see what windows reports as the drive size in each case. Here were the results:

Code:

FAT32 Format Allocation unit size        Windows Explorer Drive Size (GB)
--------------------------------------------------------------------------------
65536                                    119
32768                                    119
16384                                    119
8192                                     119
4096                                     119
2048                                     119
1024                                     118
512                                      53.6

In any case I decided to just go with a 2KB unit size because it's the smallest setting that reports the drive's complete size in Windows. My original intention was to just choose the smallest size to minimize wasted space, but I didn't know at the time that 512 bytes would cause problems.

Actually the 118GB value is correct.

When you use a smaller cluster size your file allocation table proportionally increases in size. With a 1KB cluster size on a 128GB drive the FAT is about 500MB. And there are 2 copies of it so you have about 1GB reserved for the FATs.

With a 2KB cluster size that size is cut in half. So taking into account rounding you should see a ~0.5GB difference in usable space between a 1KB and 2KB cluster size drive.

Note that Microsoft defaults to 32KB cluster sizes for drives > 32GB.

Code:

/* 
* This is the table for FAT32 drives. NOTE that this table includes
* entries for disk sizes smaller than 512 MB even though typically
* only the entries for disks >= 512 MB in size are used.
* The way this table is accessed is to look for the first entry
* in the table for which the disk size is less than or equal
* to the DiskSize field in that table entry. For this table to
* work properly BPB_RsvdSecCnt must be 32, and BPB_NumFATs
* must be 2. Any of these values being different may require the first 
* table entries DiskSize value to be changed otherwise the cluster count 
* may be to low for FAT32.
*/
    DSKSZTOSECPERCLUS DskTableFAT32 [] = {
        {       66600,   0},  /* disks up to 32.5 MB, the 0 value for SecPerClusVal trips an error */
        {     532480,   1},   /* disks up to 260 MB,  .5k cluster */
        { 16777216,   8},     /* disks up to     8 GB,    4k cluster */
        { 33554432, 16},      /* disks up to   16 GB,    8k cluster */
        { 67108864, 32},      /* disks up to   32 GB,  16k cluster */
        { 0xFFFFFFFF, 64}/* disks greater than 32GB, 32k cluster */
    };

PolarNettles said:

Actually the 118GB value is correct.

When you use a smaller cluster size your file allocation table proportionally increases in size. With a 1KB cluster size on a 128GB drive the FAT is about 500MB. And there are 2 copies of it so you have about 1GB reserved for the FATs.

With a 2KB cluster size that size is cut in half. So taking into account rounding you should see a ~0.5GB difference in usable space between a 1KB and 2KB cluster size drive.

Note that Microsoft defaults to 32KB cluster sizes for drives > 32GB.

Code:

/* 
* This is the table for FAT32 drives. NOTE that this table includes
* entries for disk sizes smaller than 512 MB even though typically
* only the entries for disks >= 512 MB in size are used.
* The way this table is accessed is to look for the first entry
* in the table for which the disk size is less than or equal
* to the DiskSize field in that table entry. For this table to
* work properly BPB_RsvdSecCnt must be 32, and BPB_NumFATs
* must be 2. Any of these values being different may require the first 
* table entries DiskSize value to be changed otherwise the cluster count 
* may be to low for FAT32.
*/
    DSKSZTOSECPERCLUS DskTableFAT32 [] = {
        {       66600,   0},  /* disks up to 32.5 MB, the 0 value for SecPerClusVal trips an error */
        {     532480,   1},   /* disks up to 260 MB,  .5k cluster */
        { 16777216,   8},     /* disks up to     8 GB,    4k cluster */
        { 33554432, 16},      /* disks up to   16 GB,    8k cluster */
        { 67108864, 32},      /* disks up to   32 GB,  16k cluster */
        { 0xFFFFFFFF, 64}/* disks greater than 32GB, 32k cluster */
    };

Interesting, I didn't know that. For some combinations of drive size and cluster size the rule of thumb that "smaller cluster size saves space" may not hold true due to the larger file allocation table.

What started as formatting a USB drive for use in my car ended up as a basic lesson in filesystems.