GNOME Bugzilla – Bug 763896
GParted not restricting creation of FAT32 volume to maximum size of 2 TiB
Last modified: 2016-04-26 15:56:16 UTC
First raised in this GParted Forum post: Topic: Gparted and fat32FS on 3TB HDD http://gparted-forum.surf4.info/viewtopic.php?pid=33955 GParted is allowing creation of a FAT32 formatted partition of any size. However with a 512 byte sector size the maximum volume size of a FAT32 file system is reported to be 2 TiB. * Wikipedia: File Allocation Table / FAT32 https://en.wikipedia.org/wiki/File_Allocation_Table#FAT32 "The boot sector uses a 32-bit field for the sector count, limiting the FAT32 volume size to 2 TB for a sector size of 512 bytes and 16 TB for a sector size of 4,096 bytes." * Microsoft: Default cluster size for NTFS, FAT, and exFAT / Default cluster sizes for FAT32 https://support.microsoft.com/en-us/kb/140365 Trying to create a FAT32 file system in a partition larger than 2 TiB results in unallocated space being left after the file system. Nuances: [1] Larger sector sizes allow larger maximum volume sizes up to 16 TiB with 4096 byte sectors. [2] mkdosfs/mkfs.fat has an -S SECTOR_SIZE option which allows changing the "logical" sector size of the file system allowing the maximum volume to be proportionally increased. [3] mkfs.fat appears to have an signed overflow bug when the size of the partition is larger than maximum signed 32-bit integer of logical(?) sectors. (2 TiB for a sector size of 512 bytes). It reports the partition size as minus size and creates a 1 TiB file system. GParted wants a single maximum file system size and the code is not ready for a differing maximum file system size for different sector sizes. In fat::create() could specify larger "logical" sector sizes to mkfs.fat when the partition is larger than 2 TiB to allow maximum volume size to be increased further. However that will take a lot of cross platform testing to ensure that all sorts of devices support "logical" sector sizes other than 512 bytes on devices with a hardware sector size of 512 bytes. This is too much effort. Therefore implement a single FAT32 maximum volume size of 2 TiB.
Created attachment 324336 [details] [review] Limit FAT32 maximum volume size to 2 TiB (v1) Hi Curtis, Here's the patch for this. Limiting FAT32 to 2 TiB seems like the simple thing to do. Thanks, Mike Other notes: I had a test of the other file systems and there are several which limit the maximum volume size to 16 TiB (2^32 * 4 KiB block size). They are: ext2, ext3, ext4 (older tools without 64bit support), reiserfs. Not doing anything about these. Other file systems are happy to create volumes larger than this. (Reiser4 not tested). Also found that on CentOS 7 and recent Fedora distros that partition /dev entries are automatically created for partitioned loop devices.
Thank you Mike for implementing a FAT32 maximum size limit. For testing I used the following steps: 1) Create a big device (3 TiB) using a sparse file. IMGFILE=bigdev.img truncate -s 3145728M $IMGFILE sudo losetup /dev/loop0 $IMGFILE 2) Run GParted 0.25.0 and test GPT/FAT32 partition create (1/2/3 TiB). sudo gparted $IMGFILE RESULT: GUI permits all three of 1/2/3 TiB FAT32 create operations. 3) Run GParted with patch and test GPT/FAT32 partition create (1/2/3 TiB). sudo src/gpartedbin $IMGFILE RESULT: GUI permits both 1/2 TiB FAT32 create operations. GUI prevents 3 TiB FAT 32 create operation. Largest FAT32 size permitted is 2,097,152 MiB. 4) Remove big device. sudo losetup -d /dev/loop0 rm $IMGFILE Based on the results this patch works as expected. The patch in comment #1 has been committed to the git repository. The relevant git commit can be viewed at the following link: Limit FAT32 maximum volume size to 2 TiB https://git.gnome.org/browse/gparted/commit/?id=2bb78cf8dc0028fc5d01044655a7cf12bb01d95d Note that after I pushed the commit I noticed that we forgot to append the bug number to the git title. For example: Limit FAT32 maximum volume size to 2 TiB (#763896). Ah well. This is very minor in the big scheme of things and does not affect the operation of the code. Curtis
> GParted wants a single maximum file system size and the code is not > ready for a differing maximum file system size for different sector > sizes. I propose a new API call for FS wrappers. I can implement it for FAT family. size_t max_sectors_allowed_smallest(uint16_t log2sectorsize) Returning maximal number of allowed sectors with at least given sector size.
This enhancement was included in the GParted 0.26.0 release on April 26, 2016.