File Allocation Table (“FAT”) Filesystem Format Family

Quick overview of variations
FAT32

Microsoft KB Q154997: Description of the FAT32 File System

Size limits
Volume minimum size limit

There have been various limits posted.

In practice, it has been found that Windows 7 has created a FAT32 drive that was 30014 KB (30,734,336 bytes, a bit under 30 MB). This is noted by Gala's StackOverflow.com question called “FAT32 File Allocation Table size on Windows 7 formatted drive is out of FAT32 specification”. It is not clear whether the drive worked okay, but being that both Microsoft Windows and Kingston drives (which is what that example was based off of) were widely-used technologies, one would presume that probably worked okay.

A more official-looking short answer is: Probably 32,763.5 KB (33,549,824 bytes), which is just 4.5 KB (4,608 bytes) under 32 MB (33,554,432 bytes). However, as noted above, the reality seems to work despite being less than that theoretical size limitation. Also, the real limit may actually be affected by hardware, so if an actual technically-accurate number were determined, that limit might not be achievable with some hardware. (e.g., for drives using 4KB sector size, to achieve the 65,527 cluster requirement, would need 262,108 KB = 268,398,592 bytes = a bit over 255.96 MB, but drives using the 512e format would not have that same space requirement.)

The longer answer is that documentation has provided some differnet information. MS KB 140365: “Default cluster size for filesystem formats commonly used on hard drives” (also at Microsoft KB 140365, shorter URL, and formerly at http://support.microsoft.com/support/kb/articles/Q140/3/65.ASP) mentions that FAT32 doesn't support sizes under 16MB, but does indicate that FAT32 is supported for sizes from 16MB to 32MB in Windows NT (3.51 and 4.0), and that sizes from 32MB and higher may be supported by both these Windows NT versions as well as Windows 2000, XP, and newer (at least up through Windows Server 2008).

Then again, that information is questionable. This support for partitions from 16MB to 32MB is only supposedly supported by Windows NT. However, MS KB Q314463: “Limitations of the FAT32 File System in Windows XP&” (as archived by the Wayback Machine @ Archive.org from February 24th, 2015) (previously at http://support.microsoft.com/support/kb/articles/Q314/4/SPAN>63.ASP) has documented, “MS-DOS, the original version of Microsoft Windows 95, and Microsoft Windows NT 4.0-and-earlier do not recognize FAT32 partitions, and are unable to start from a FAT32 volume.” Actually, the original release of Microsoft Windows 95 did not support FAT32, but Windows 95 Operating System Release 2 (Win95 OSR2) did support FAT32. (Win95 OSR2 was only distributed in OEM format, so it only came on new computers. Win95 OSR2 was not released in the retail market, so the first operating system that consumers could buy to use FAT32 was Microsoft Windows 98.)

There is a documented limit of a minimum size of 65,527 clusters. Although, 65,527 clusters, even if using clusters as small as a half-kilobyte, would still be 33,549,824 bytes which would be notably larger than the 16MB limit supported by Windows NT. The 65,527 cluster limit has been documented in multiple locations. TechNet: Maximum Volume Sizes notes, “The FAT32 volume must have at least 65,527 clusters.” (This minimum that affects size is also noted by Microsoft KB Q184006: “Limitations of the FAT32 File System”, as archived in November of 2001, by the Wayback Machine @ Archive.org (for Win98 Std, ME, 2K) and MS KB Q314463: “Limitations of the FAT32 File System in Windows XP&” (as archived by the Wayback Machine @ Archive.org from February 24th, 2015) (previously at http://support.microsoft.com/support/kb/articles/Q314/4/SPAN>63.ASP). Also, Microsoft Documentation: “UEFI/GPT-based hard drive partitions”, section called “Drive Partition Rules” is some newer documentation (as it was at least updated around the time of Windows 10), and it references the 65,527 cluster limit a couple of times.

That number of clusters is a bit less than 65,536 (which 64 x 1024), so the actual minimum might be less than some numbers that are commonly seen. For instance, Microsoft KB Q192322: FAT32 Cluster Sizes provides cluster sizes of 4 KB. So math would indicate the minumum size to be size, 65,527x4096 bytes = 268,398,592 bytes, which is over 255.96 MB but not quite 256 MB.

Old info

There has been some information posted that FAT32 might have a minimum size limit of a half-gigabyte. For instance, Microsoft KB Q69912: MS-DOS Partitioning Summary (formerly at http://support.microsoft.com/support/kb/articles/Q69/9/12.ASP) which shows partition types 0x0B and 0x0C. Microsoft KB Q192322: FAT32 Cluster Sizes (formerly at http://support.microsoft.com/support/kb/articles/Q192/3/22.ASP) puts this very clearly, saying, “Note that the FAT32 file system does not support drives smaller than 512 MB.”

This website did provide some misleading/bad information. referencing the 65,527 limit, it noted, “(If clusters are 8,032.5KB each, that would be 8032.5Kx65527=almost 502MB. If clusters are 8,064KB each, this would be almost 504MB.)” However, the amount of 8032.5KB would be a common size of a cylinder on some IDE/PATA drives. Cluster sizes are likely to be notably smaller than that. So the text seems to have mistaken a “cylinder” for a “cluster”. (Fortunately, this did start with the world “If”, so that wasn't technically an inaccurate statement. Also, fortunately, this was in parenthesis.)

Volume maximum size limit
Fast answer for common use

Operating system limitations, rather than limitations by the filesystem format design, have tended to be the impactful limits. 133,693,376 KB (130559.9375 MB, a bit under 127.49994 GB) is the largest size that works well with the ScanDisk program from Windows 95 and Windows 98, and has been documented to be the largest mountable size by Windows 2000. (That documented limit for Windows 2000 has been contradicted by other documentation, but it is still documentation that some technicians may have seen.)

The ScanDisk program is often a reasonable program to use to check a disk, and so staying within that limit is recommended (rather than slightly exceeding that limit). This is quite close to the maximum size of the LBA28 limit (136,902,082,560 bytes = 127.5 GB, which comes from 65,535 cylinders x 16 heads x 255 sectors x 512 bytes per sector). Exceeding the LBA28 limit is quite likely to cause some compatability issues, so the 129,613,440KB limit (as described not long ago) ends up being the largest size that is very widely supported without problems that are likely severe enough to generally want to avoid. (If somehow the LBA28 limit and all smaller limits became non-impactful, the 2 TB limit of the MBR format would likely be an issue with most common implementations of FAT32.)

So, the general recommendation is to use 133,693,376 as a maximum size, but also to simply be aware of the 32GB limit of Win2K/XP/newer's formatting tool.

Details when using Microsoft Windows operating systems

Windows 2000 and Windows XP and later cannot create a FAT32 partition over 32 GB, although the “FastFAT” driver used by these operating systems will have no problem working with pre-created drives that are over 32GB in length. The specific problem with Win2K/XP/later is that the format tool will claim “Logical Disk Manager: Volume size too big.” According to WindowsITPro.com: “Understanding File-Size Limits on NTFS and FAT”, “This limitation is by design: Microsoft wants you to use NTFS for large drives.”

Other than that limit with creating drives with those specific operating systems, 133,693,376 KB is the basic limit. The way that number was calculated is about to be described.

MS KB Q184006: Limitations of FAT32 File System states, “Clusters cannot be 64 kilobytes (KB) or larger. If clusters were 64 KB or larger, some programs (such as Setup programs) might calculate disk space incorrectly.” So, as a standard, the maximum cluster size ends up being 32 KB.

The core of the limit seems to be from a combination of math related to disk space, and also memory handling. For Win95/98 (and perhaps not Windows ME?), MS KB Q184006: Limitations of FAT32 File System discusses this in detail: The program cannot support a file allocation table larger than 16,320 KB (which is 16,777,216 (16MB) minus 65,536 bytes (64KB)) due to memory limitations (which is a limit unrelated to disk size). This 16,711,680 bytes of memory, divided by 4 bytes for the size of each cluster, results in 4,177,920 clusters that can be tracked in that much memory. (4,177,920 is evenly dividable by 1,024, so the 16,320 KB is sufficient for storing 4,080 Kiloclusters. Huh? Kiloclusters?)

For Win95/98 (and probably not Windows ME?), MS KB Q184006: Limitations of FAT32 File System notes that ScanDisk does not want to see anything larger “than 4,177,920 clusters (including the two reserved clusters”. TechNet: Maximum Volume Sizes refers to a maximum of 4,177,918 sectors. The page later notes, about Windows 2000, that: “It is possible to mount volumes that exceed these limits, but doing so has not been tested and is not recommended.” (Hmm... if it has not been tested, how does the author know that it is possible? The statement might have meant “officially, thoroughly tested”. Or maybe it was really just an entirely untested statement based on how the source code was expected to work?) Apparently ignoring that statement about what is actually possible, TechNet: File Systems states, “The maximum number of clusters that Windows 2000 can mount on a FAT32 volume is 4,177,918.” So, for multiple Microsoft operating systems, it seems that 4,177,918 usable sectors (plus two reserved sectors) is the maximum size that is generally considered to be supported.

Rowan Hawkins's comment to his own answer on a RetroComputing.StackExchange.com page notes, “98 and 98SE have trouble with partitions larger than 32G and support for drives over 137G because of limitations with the ATA BIOS caused by that generation hardware, not the FAT. If you have a different controller, say a parallel SCSI controller that the drives are mounted to, then you can go up the the 8TiB limit of FAT32.” (That size would have supported drives commonly sold much later, even single drives sold decades after the release of Windows 98. Whoosh!)

Using 32 KB clusters, 4,177,918 times 32 KB ends up being 136,902,017,024 bytes (133,693,376 KB), 130,559.9375 MB which is a bit under 127.49994 GB. The MS KB notes that after the file allocation tables, the largest possible volume size is 127.53 gigabytes (GB). It is not clear exactly what math was used for the definition of a gigabyte when Microsoft made that calculation.

Win95/98/ME could support up to the maximum of LBA28, which is 127.5GB (although additional limitations from a hard drive's individual “geometry” layout might shrink this by a small amount). Windows 2000 and derived code might be able to mount such large filesystem volumes once they are operational. However, Windows 2000 and derived code may not be able to “format”(/“initialize”) a filesystem volume that exceeds 32GB. Once the drive is formatted (by any operating system), the 32GB limit is likely to impose no problems, so 127.5GB is likely available.

MSFN Forum: Post by Sfor about drive sizes states “I had a lot of problems with Windows 95 and a 160GB HDD. Windows 98 can work very good with the drives exceeding 137GB depending on the IDE drivers used. DOS is working fine if BIOS supports the LBA48.” Later, on post #11 of the page, Sfor notes, “The Fdisk from windows 9x will not accept the parttion sizes greater than” (surely what is meant is: approximately 64 GB)... “But when entering partition sizes in the % of the free disk space available, it should work correctly.”

Microsoft's clain: 127.53 GB

TechNet: Maximum Volume Sizes says “The maximum volume size that Windows 98 can create is 127.53 GB”. The page later says “127.53 GB and 4,177,918 clusters from a volume formatted with the limits of Windows 98”. Similarly, TechNet: Filesystems documents the 127.53 GB and 4,177,918 size maximum. MS KB 184006: Limitations of FAT32 File System documents a limit of “4,177,920 clusters (including the two reserved clusters)”. 4,177,918 clusters using a 32KB cluster size would be 136,902,017,024 = 136,902,017,024 KB = a bit less than 127.49994 GB.

It is not known just how this number was calculated. Using the smaller numbers (129,613,440KB) seems like a safer guideline.

Other theoretical limits

The actual upper limit of FAT32 is about 2TB, as noted by Microsoft KB Q186892: the \Tools\Mtsutil\Fat32ebd\Fat32ebd.txt on the Windows 98 CD-ROM. This might have just been a theoretical upper limit to the implementation. Getting above 2TB will require using a disk layout other than the traditional MBR format.

Microsoft KB Q314463: Limitations of the FAT32 File System in Windows XP says, “The maximum possible number of clusters on a FAT32 volume is 268,435,445, and there is a maximum of 32 KB per cluster”. Microsoft KB Q184006: Limitations of the FAT32 File System (for Win98 Std, ME, 2K) says, “The maximum possible number of clusters on a volume using the FAT32 file system is 268,435,445. With a maximum of 32 KB per cluster with space for the file allocation table (FAT), this equates to a maximum disk size of approximately 8 terabytes (TB).” That many 32KB sectors would equate to 8,796,092,661,760 bytes. (The actual math is that 8 TB would be 268,435,456 x 32,768, so this ends up being 360,448 bytes short of 8 TB. 360,448 is 11 clusters of 32,768 bytes each.) So, in theory, according to that document, FAT32 can support over 99.9999959% of an 8TB size (7.9999996721744537353515625 TB) if 32KB clusters were used. However, once again, that is just theoretical. In practice, other limits tend to be more impactful, like the MBR format.

There are, however, operating system limits that are smaller than those maximum limits. Here are some notable ones by Microsoft.

  • TechNet: Maximum Volume Sizes notes, “Windows 2000 can format new FAT32 volumes up to 32 GB in size but can mount larger volumes (for example, up to 127.53 GB and 4,177,918 clusters from a volume formatted with the limits of Windows 98). It is possible to mount volumes that exceed these limits, but doing so has not been tested and is not recommended.” The cited number of clusters (4,117,918) is not counting two reserved clusters, and so is the same limitation as one discussed by Microsoft KB Q184006: Limitations of the FAT32 File System (for Win98 Std, ME, 2K). This KB Q184006 also documents the inability to format FAT32 about 32GB in Win2K. The article states, “You cannot format a volume larger than 32 GB in size using the FAT32 file system in Windows 2000. The Windows 2000 FastFAT driver can mount and support volumes larger than 32 GB that use the FAT32 file system (subject to the other limits), but you cannot create one using the Format tool. This behavior is by design.” ... “When attempting to format a FAT32 partition larger than 32 GB, the format fails near the end of the process with the following error:” “Logical Disk Manager: Volume size too big.”
  • Microsoft KB Q140365: Default cluster size for filesystem formats commonly used on hard drives (Microsoft KB 140365) (with information about NTFS, FAT, and exFAT) notes Windows NT 3.51 supports 32KB cluster sizes on volumes larger than 32GB. For the column for Windows NT 4.0, as well as the column for Windows 2K and XP and newer operating systems, the text “Not supported” is shown.
  • Some 16-bit code may have a limit of “4,177,920 clusters (including the two reserved clusters).” This quoted limitation is documented by Microsoft KB Q184006: Limitations of the FAT32 File System (for Win98 Std, ME, 2K). The reason given by that article is that the 16-bit code, such as that used by ScanDisk, may be limited in how big of a memory allocation is used to store the FAT. This limitation may be 16,711,680 bytes (16MB minus 64KB), all according to that same article (KB Q184006). The limit of 4,117,920 clusters would seem to suggest a limit of 134,936,002,560 bytes (128,685 MB = 125.6689453125 GB), although Microsoft KB Q184006: Limitations of the FAT32 File System (for Win98 Std, ME, 2K) and TechNet: Maximum Volume Sizes seem to refer to this as a 127.53GB limitation. This is entirely unrelated to the 28-bit LBA limitation.
  • The 28-bit LBA limitation may prevent use of more than 127.5GB=130,560MB=133,693,440KB=136,902,082,560 bytes, a number which comes from 64x1024 cylinders x 16 heads x 255 SPT x half a KB per sector. (This limitation is more about supporting hard drives that large, rather than being a limitation that is specific to the filesystem. However, since the filesystem must fit on a hard drive, this limit may be relevant.) (There are, naturally, other limits that may affect a computer's ability to fully utilize a hard drive. This one is pointed out here for two reasons: due to affecting Win9x, and due to being so close to the 4,117,920 cluster limit.) Win9x might be able to be coaxed into higher limits using third party limitations, but that may be problematic: Forum post for Enable48BitLBA provides compatibility for larger drives using third party code to support 48-bit LBA, but has been known to say, “this current version may cause data corruption on _some_ drives w/ 48-bit LBA!!! So be extremely careful!!!” (Perhaps that is because the patch affected the 28-bit LBA limitation, but not the 4,117,920 cluster limit?)
File maximum size limit
This can vary based on the FAT type. For FAT16 and FAT32, no file can be over 4,294,967,295 bytes (which is 1 byte less than 4GB; the number of bytes in 4GB is 2 raised to the 32nd power). (Citation: TechNet: Maximum Volume Sizes)

For FAT12, no file can be over 32MB (which is often not a problem, since FAT12 was often used for floppy disks that typically didn't store more than 2MB of total capacity anyway).

MBR partition types (supporting FAT32)

Windows 95/98 Partition Types Not Recognized by Windows NT

[#parttypb]: Partition type 0B

FAT32 primary partition. Support was added by Win95 OSR2 and Win98.

If the partition is going to contain a FAT16 filesystem volume, partition type 0x0E (or partition type 0x06) may be more appropriate.

TechNet: Disk Concepts and Troubleshooting and TechNet's “Troubleshooting Disks and File Systems” : “Disk Sectors Critical to Startup” both list this as “FAT32 partition or logical drive”, which differs from 0x0C's description of “FAT32 partition or logical drive using BIOS INT 13h extensions”. However, MS KB Q69912 says FDISK reports this as “PRI DOS” (which would suggest a primary partition), rather than “EXT DOS” (which would suggest an extended partition, and/or a logical drive intended to go into an extended partition) which is what it says for 0x0C.

[#parttypc]: Partition type 0C

Note: further research/testing may be warranted before going by this documentation, as Microsoft seems to have some conflicting documentation, as currently discussed further in the section about Partition type 0B. However, although there may be some ambiguity about whether this is used for primary partitions or extended partitions, documentation does consistently indicate this uses the Int13E support.

An extended partition which may contain FAT32 drives. Support was added by Win95 OSR2 and Win98.

Windows 95/98 Partition Types Not Recognized by Windows NT identifies this partition type (“0x0C”) as being the “Same as 0x0B” except that this “uses Logical Block Address Int 0x13 extensions”. (Hyperlink added to the quoted text.) This appears to be wrong, as it conflicts with MS KB Q69912's description that identifies 0x0C as being Extended. Rather, 0x0C seems to be like 0x0F. Microsoft KB Q69912: MS-DOS Partitioning Summary says “Types 0E, 0F, and 0C require extended Int13 support.” Further details about choosing a “partition type” identifier for an “extended partition” are avaiable in the section describing Partition Type F.

Other info/overview by Microsoft

Microsoft KB Q154997: Description of the FAT32 File System, Microsoft KB Q253774: Common questions about FAT32.

Compatability
Secure Digital High Capacity (SDHC)

FAT32 was used by the Secure Digital High Capacity (SDHC) format. Windows XP did not support SDHC until a patch was applied, although this support was included by XP SP3. Windows Vista also required an update. This is described further by Wikipedia's article on Secure Digital: Section about SDHC (Secure Digital High Capacity format).

Compatability options for some older operating systems
OS/2
http://www.chat.ru/~ashedel/fat32/fastfat32.rar
TLDP documentation on FAT32 for OS/2 refers to a os2fat32.zip IFS (installable filesystem) which provided support for FAT32 and long filenames, but not OS/2 extended attributes. Installing OS/2 and FAT32 notes some additional problems caused when using OS/2 Fixpak 13 or Fixpak 14, and seems to recommend using DaniDASD.DMD. (That article also seems to refer to Fixpak 15 as a still-unrelased Fixpak, and notes that FAT32 compatability issues were “confirmed by IBM to be THE current "hot" item on the problem list for resolution (hopefully) with FP15.”
WinNT

TLDP documentation on FAT32 for NT(anonymous creation) referred to a “Free or GPL ?” “FAT32 filesystem driver for NT 4.0 and NT 3.51” at http://www.chat.ru/~ashedel/fat32/fastfat32.rar which does not seem to be available any longer (at that address). Also, SysInternals (Mark Russinovich and Bryce Cogswell) had released some read-only freeware and sold a read-write version (according to TLDP documetnation on FAT32 support by SysInternals. That probably suffered the same fate as the NTFS driver for DOS, becoming unavailable when SysInternals became bought out.

[#fatpre32]: Pre-FAT32 FAT

Sometimes the abbreviation FAT basically just refers to FAT16 or FAT12 as appropriate.

[#fat16]: FAT16

Note that when FAT16 compatability is mentioned, many times support is actually provided for Pre-FAT32 FAT (meaning that support exists for both FAT16 and also FAT12).

[#fat16siz]: Size limits
Minimum size limit

Microsoft KB Q69912: MS-DOS Partitioning Summary shows that FAT16 is used for as low as 16MB. (Below that, FAT12 may be used. In the name “FAT16”, the “16” is commonly understood to refer to the number of bits in the FAT, especially after FAT32 was released. The common understanding is not that the “16” somehow refers to this minimum size limit of 16MB.)

(For a FAT partition that is less than 16 MB, FAT12 is an available option. Software/platforms that support FAT16 will typically also support FAT12, even if that support is not documented.)

Maximum size

The actual limit for FAT16 is 65,535 clusters, as documented by TechNet: Maximum Volume Sizes.

One maximum size that can be found implemented would be 4,294,901,760 bytes (4,194,240KB=4,095.9375 MB=3.99993896484375 GB) if 64KB clusters are being used. However, many implementations will not fully support anything above 32KB clusters well. Such implementations do not support anything above 2,147,450,880 bytes (which is 2,097,120KB=2,047.96875=MB=and 1.999969482421875 GB). (Many of these numbers are a tad under a power of two, and that is because the limit is 65,535 clusters, which is one cluster less than a power of two.)

Microsoft KB Q140365: Default cluster size for filesystem formats commonly used on hard drives (Microsoft KB 140365) notes that Windows NT 4.0 may support FAT16 cluster sizes of 128KB and 256KB on media with a sector size greater than 512 bytes. Presumably the latter would allow for a FAT16 partition of up to 17,179,607,040 bytes=16,776,960KB=16,383,75MB=15.999755859375 GB.) This does match Q140365's documentation, showing 128KB cluster sizes for filesystem volumes up to 8GB in size, and 256KB cluster sizes for filesystem volumes up to 16GB in size. However, support for cluster sizes over 64KB was dropped by Windows 2000.

Examples of limitations of nearly 2GB per FAT16 filesystem include support by DOS, Win9x, and Secure Digital (SD) memory cards. (Larger cards using specifications by the same Secure Digital standards body do exist, but those cards use the Secure Digital High Capacity (SDHC) standard, not FAT16 like the older SD standard.) TechNet: Maximum Volume Sizes states that a 64KB “cluster size is known to create compatibility issues with some applications. For this reason, it is recommended that FAT32 be used on volumes that are between 2 GB and 4 GB. One of the known compatibility issues involves setup programs that do not compute volume free space properly on a volume with 64 KB clusters and will not run because of a perceived lack of free space. The Format program in Windows 2000 displays a warning and asks for a confirmation before formatting a volume with 64 KB clusters.”

Note that for a partition using a size of anywhere from 65,527 clusters through 65,535 clusters, FAT16 may be a possibility but FAT32 may also be a possibility. If the software that will be used supports FAT32, then FAT32 may be able to result in a smaller cluster size, resulting in less disk space being wasted.

Cluster size note

The default cluster size for drives of 512MB to under 1GB is 16KB, and larger filesystems will use a larger default cluster size. In contrast, FAT32 uses 4KB cluster sizes for drives smaller than 8GB (and at least 512 large), so if software supports FAT32 then there may be less waste by using that format. (Citation: TechNet page: FAT16 vs. FAT32)

[#fatprtyp]: FAT's Partition “type” identifiers

The choices needed for partition types related to FAT drives is particularly complex; moreso than other standard filesystem types. This is because other filesystem types simply evolved the filesystem drivers, but the people behind the FAT standard decided to adjust the MBR partition type identifiers when new technologies allowed for larger drives. Some details are in the section on MBR partition types: Common partition types of DOS and similar (OS/2, Microsoft Windows).

Also, following are some details for MBR-style partition type identifiers related to FAT16. (For even more options, consider also the partition type identifiers related to FAT32.)

Microsoft KB Q69912: MS-DOS Partitioning Summary (formerly at http://support.microsoft.com/support/kb/articles/Q69/9/12.ASP) provides some nice details.

To determine the partition type identifier:

  1. start by determining whether a primary partition is desired, or an “extended partition” containing “local drives”
  2. Determine whether you're using FAT32 or an earlier FAT version.
  3. Then, if you're using a FAT version before FAT32, determine whether Microsoft's implementation of using INT13e (INT13h Extensions, or “extended Int13”) to support LBA28 (28-bit LBA) is required.
    • (This implementation, used by Microsoft, is not used by OS/2, even though Microsoft and IBM did work together when creating OS/2.)
    • If you're using a Microsoft operating system, determining this (whether INT13e's LBA28 support is needed) typically means checking whether the partition uses more than 1,024 cylinders. (Since the first cylinder number is zero, this means using a cylinder with a cylinder number bigger than 1,023.)
      • This is often at (or near?) 504 MB (516,096 KB, 528,482,304 bytes), which comes from 1024 Cyl x 16 Head x 63 Sec/Track x 512 byte sectors). (At the time this issue started to occur, 540MB drives were being made, and might have been among the first drives to encounter this issue. Sometimes the limit is referred to as a 504MB limit (which is good), or a 512 MB limit (which is approximately/near right), or 516MB (number of KB), or 528MB (based on being about 528.4 million bytes), or 540MB (affecting maximum-size partitions on drives that are this big).
  4. Finally, keep in mind what size is being used.
    • Namely, this is to figure out whether the drive is under 16MB, or over 32MB, or neither. As disk space is much more plentiful than when these DOS versions shipped, chances of being 32MB are very good. Commercial hard drives that don't support that much disk space are multiple decades old.

(After this chart, there is some documentation that was created before this chart.)

This chart likely looks similar to information in the section about “Windows 95 OEM Service Release 2 and Windows 98” of MS KB 69912. The reason the charts have similarities is because these charts covers much of the same information (and MS KB 69912 was used as a resource when making this chart).

In this chart, Pri means “primary”. “Log” means a “logical drive” which goes into an “extended partition”-style setup.

Type/ID Style FAT
ver
INT13e's
LBA28
support?
Usage
1 Pri FAT12 No
  • 0-15MB (FAT12, first supported by MS-DOS 2)
4 Pri FAT16 (Small) No
  • 16MB - 32MB (small FAT16, first supported by MS-DOS 3)
5 Log FAT12/
FAT16
No
  • Logical Drive, not using Microsoft's implementation using INT13h's LBA28 support.
    • For OS/2, this is the only partition type needed for a logical drive, in an extended partition (which may use FAT12 or FAT16)
    • For Microsoft software, this is for drives that don't use INT13e's LBA28 support. Generally, that means not extending past cylinder 1,024 of hard drive geometry. (Partition type F is used for such large extended partitions.)
      • Used for a logical drive using FAT12 and/or FAT16 filesystem volumes. For logical drives using FAT32, see type C.
      • First supported by MS-DOS 3.3
6 Pri FAT16 No
  • FAT16 partitions exceeding 32MB...
    • For OS/2, this is used for drives over 32MB, regardless of how large this is.
    • For Microsoft software, this is for drives that don't use INT13e's LBA28 support. Generally, that means not extending past cylinder 1,024 of hard drive geometry. (Partition type E is used for such large extended partitions.)
      • Used for a logical drive using FAT12 and/or FAT16 filesystem volumes. For primary drives using FAT32, see type B.
      • First supported by MS-DOS 4.0
B P? FAT32 N/A
  • FAT32 partitions (512MB+)
    • First supported by Win95 OSR2
    • Perhaps a primary partition? Further discussion at Partition type 0x0B.
    • (MS KB 69912 documents this as maxing out at 2TB, which is the MBR's limit. However, FAT32 may max out earlier, due to LBA28's limit.)
  • Not used for FAT12 or FAT16. For such drives, see 1 or 4 or 6 or E.
C L? FAT32 N/A
  • FAT32 partitions (512MB+)
    • First supported by Win95 OSR2
    • Perhaps a logical drive (in an extended partition)? Perhaps a primary partition? Further discussion at Partition type 0x0B. (Yes, the section about 0x0B.)
    • (MS KB 69912 documents this as maxing out at 2TB, which is the MBR's limit. However, FAT32 may max out earlier, due to LBA28's limit.)
  • Not used for FAT12 or FAT16. For such drives, see 5 or F.
E Pri FAT16 Yes
  • FAT16 partitions exceeding 32MB, using Microsoft's support for INT13e's LBA28 support
    • Generally, that means extending past cylinder 1,024 of hard drive geometry, and not exceeding 2GB. (Partition type 6 is used for smaller partitions, and for OS/2.)
    • First supported by Win95
    • Not used by OS/2. (OS/2 would use type partition type 6 for such partitions.)
F Log FAT12/
FAT16
Yes
  • Logical Drive partition, exceeding 32MB, using Microsoft's support for INT13e's LBA28 support. Used for partitions containing FAT12 and/or FAT16 partitions.
    • Generally, that means extending past cylinder 1,024 of hard drive geometry, and not exceeding 2GB. (Partition type 5 is used for smaller partitions, and for OS/2.)
    • First supported by Win95
    • Not used by OS/2. (OS/2 would use type partition type E for such partitions.)
    • Not used for FAT32. (For FAT32, see type C.)

The following information may be redundant with the prior chart; the documentation was made before the prior chart. (This older documentation was left remaining here, in case having this information outside of a chart is somehow easier/useful for anyone.)

[#parttyp4]: Partition type 04

A primary partition ranging from 16MB to 32MB, residing in the first 32MB (without needing to use INT13e support). Support started with MS-DOS 3.0, accoridng to Microsoft KB Q69912: MS-DOS Partitioning Summary. Wikipedia's article on File Allocation Table (FAT): section titled “Initial FAT16” describes very early support of FAT, including some early FAT support by various MS-DOS versions (including MS-DOS 2.x).

Wikipedia's article on File Allocation Table (FAT): section titled “Final FAT16” says, “In practice however, type 0x01 and 0x04 primary partitions should not be physically located outside the first 32 MB of the disk, due to other restrictions in MS-DOS 2.x, which could not cope with them otherwise.”

Wikipedia's article on “Partition Type”, footnote #1 says, “ MS-DOS/PC DOS 2.0-3.1 cannot cope with hard disk partitions outside the first 32 MB of the disk. Therefore, FAT12 and FAT16 volumes in primary partitions physically residing outside this area must not use partition IDs 01h and 04h, even if they were otherwise small enough to be recognized by these DOS versions. In order to hide these volumes from these DOS issues 06h can be used instead.”

[#parttyp5]: Partition type 05

An extended partition (up to 2GB in size), with support starting as early as MS-DOS 3.3.

Maximum size by Microsoft software

This type of partition will not be using the INT13 extensions that provide LBA28 support. Therefore, (with Microsoft Windows 98 and operating systems designed to operate the same way), this type of partition should generally not be used for partitions that extend past the 1,024 cylinder of hard drive geometry. (Instead, consider using partition type 0x0f.)

Windows 95/98 Partition Types Not Recognized by Windows NT identifies partition type “0x0F” as being the “Same as 0x05” except that this “uses Logical Block Address Int 0x13 extensions”. (Hyperlink added to the quoted text.)

Other platforms

See discussion under partition type 0x0F: specifically the discussion on Determining which “partition type” identifier to use for an “extended partition”.

[#parttyp6]: Partition type 06

A primary partition ranging from 32MB up to 2GB, without using support for LBA28 using INT13 extensions. Support started as early as MS-DOS 4.0. Wikipedia's article on File Allocation Table (FAT): section titled “Final FAT16” identifies this level of support as having various names, including FAT16B and BigFAT and BIGDOS and “DOS 3.31 Large File System”.

Windows 95/98 Partition Types Not Recognized by Windows NT identifies partition type “0x0E” as being the “Same as 0x06” except that this “uses Logical Block Address Int 0x13 extensions”. (Hyperlink added to the quoted text.)

The decisions on whether to use partition type 0x06 or partition type 0x0E or partition type 0x0B are likely going to use similar reasoning as a decision on whether to use partition type 0x05 or partition type 0x0F or partition type 0x0C. Those details are discussed further in the section about determining which type of extended partition to use.

[#parttpxe]: Partition type 0E

A primary partition ranging from 16MB to 2GB using support for LBA28 using INT13 extensions. For Microsoft Windows 95, a primary partition that goes past the 1,024 cylinder may be created using 0x0E, rather than 0x05. Support for this partition type was released with Win95 (although it was buggy: MS KB Q148821 cites an issue of potential data loss unless an update is applied).

Note: For drives of 512MB or larger, partition type 0x0B seems to also fits the size ranges supported by this partition type. The difference is that a partition using the 0x0E type is intended to have a FAT16 filesystem volume, while a partition using the 0x0B will be intended to have a FAT32 filesystem volume.

Windows 95/98 Partition Types Not Recognized by Windows NT identifies this as being the “Same as 0x06” except that this “uses Logical Block Address Int 0x13 extensions”. (Hyperlink added to the quoted text.)

Note: For drives of 512MB or larger, partition type 0x0B seems to also fits the size ranges supported by this partition type. The difference is that a partition using the 0x0B type is expected to possibly contain a FAT32 filesystem volume. If that is not the case, then 0x0E may be preferred, as it is supported by Windows 95's original release.

A drive using partition type 0x0E also fits in the size range of partition type 0x06. If using OS/2, using partition type 0x06 may be preferred. Otherwise, the msot common standard may be to use 0x0E whenever the partition end of the partition is beyond the first 8,064 MB of space on the disk. (This is similar to some of the logic used when determining which type of extended partition to use.) Although that is a general recommendation, using 0x0E may be required in some specific cases. (Specifically, 0x0E may be needed for some versions of Microsoft Windows, when using the LBA28 support for INT13 extensions, which is used when the partition's end is past 8,064 MB of disk space.)

[#parttypf]: Partition type 0F
[#extprtyp]: Determining which “partition type” identifier to use for an “extended partition”

There are some clear-cut cases: Using partitions under 1,024 cylinders (8064 MB or less) should use partition type 0x05. Using partitions over 1,024 cylinders which will be using FAT32 should certainly be using 0x0C. However, some of the other combinations may need a bit more description to determine the best choice of partition type.

When to use 0x05 rather than newer types (0x0F, 0x0C)
Small partitions (under about 8GB)

DFSee documentation: FDISK-specific commands says, “When all FAT16 partition are below cylinder 1024, there seems to be NO VALID REASON to use this type, and it can be safely changed back to 0x05 to allow access by DOS, OS/2 and others.” If the partition does end up getting created as a 0x0F type, but the partition ends prior to cylinders number 1024, then switching back to 0x0F is preferred (to maximize compatability). The number of cylinders is technically dependent on the hard drive geometry, but a common value of the size for this barrier is “exactly 8064 MB” (as quoted by Wikipedia's overview on Interrupt 13H).

Microsoft Windows

This supports an extended partition using INT13 extensions. Support for this partition type was released with Win95 (although it was buggy: MS KB Q148821 cites an issue of potential data loss unless an update is applied). Microsoft KB Q69912: MS-DOS Partitioning Summary shows this may be used for drives up to 2GB in size. The difference between 0x0F and 0x05 is that 0x0F requires INT13H extensions for LBA28. However, in practice, 0x05 is preferred whenever INT13H extensions for LBA28 are unnecessary. So, the preferred breakdown for Windows 98 (or a Windows 95 with update) is:

  • Size 0MB - 8064 MB: Use type 0x05
  • Above 8065 but still 2GB or less: 0x0F
  • Exceeding 2GB: 0x0C

The reason for the 2GB cut-off point is that is the maximum filesize for some versions of FAT16, so larger drives would need to be FAT32. (This is not necessarily true for all implementations of FAT16. However, FAT32 is probably more widely supported than FAT16 implementations that are above 2GB.)

IBM (OS/2)

Andries E. Brouwer's Partition Guide, Properties of partition tables, section 2.12 “Details for various operating systems” says “OS/2 FDISK does not know about type f, but accepts DOS Extended Partitions extending beyond cylinder 1023. When some other partition handler, like Partition Magic 4.0, changes the type of a large extended partition from 05 to 0f, OS/2 loses access.” Therefore, unfortunately Windows 98's newer methods are not compatible with how OS/2 had already implemented things. (Note that OS/2 may have changed support at some time? Perhaps Fixpak 15 for OS/2 Warp 4 added FAT32 support?)

IBM documentation on Linux has stated, “our extended partition (/dev/sda3) is type 5.” (That may have just been referring to a specific example.)

Other platforms

It seems that the most common implementation (by updated open source implementations) of handling these partition types is similar to the bahvior found by Microsoft Windows 98.

Windows 95/98 Partition Types Not Recognized by Windows NT identifies this as being the “Same as 0x05” except that this “uses Logical Block Address Int 0x13 extensions”. (Hyperlink added to the quoted text.)

When using newer types, whether 0x0F or 0x0C is preferred

Note: For drives of 512MB or larger, partition type 0x0C seems to also fits the size ranges supported by this partition type. The difference is that a partition using the 0x0C type is expected to possibly contain a logical drive that uses a FAT32 filesystem volume. If that is not the case, then 0x0F may be preferred, as it is supported by Windows 95's original release.

(Since this section is in the FAT16 section, it doesn't include the details about FAT32's Partition type 0B (Primary) and Partition type 0C (Logical/Extended) partitions.)

[#prtbegcy]: Disk layout notes: Placing partitions at the start of a cylinder

(This may be redundant with FAT16 size limits and/or information at partition sizes?)

Although the size of FAT16 is often quoted to be 2GB at maximum, that isn't entirely accurate. First of all, Microsoft KB Q140365: Default cluster size for NTFS, FAT, and exFAT (formerly at http://support.microsoft.com/support/kb/articles/Q140/3/65.ASP) shows Windows NT 3.51, Windows 2000, XP and newer support 4GB FAT16 while Windows NT 4.0 also supports 16GB FAT16. The 2GB limitation commonly cited is the result of various factors.

Microsoft KB Q67321: FAT Type and Cluster Size Depends on Logical Drive Size (formerly at http://support.microsoft.com/support/kb/articles/Q67/3/21.ASP )

In practice the practical limit is often caused by a variety of factors, including an 8032.5KB (that is 255 heads x 63 SPT x 512 bytes/sector) cylinder size times 261 cylinders, resulting in 2,146,798,080 bytes. 2,146,798,080 bytes is 2,096,482.5KB, about 2047.3MB, and a bit under 1.9994GB. That is 669.5KB less than 2GB. This number of 2,096,482.5KB involves about 317.5KB being lost due to common hard drive geometry, compared to the maximum size of Microsoft KB Q118335: Maximum Partition Size Using FAT16 File System (formerly at http://support.microsoft.com/support/kb/articles/Q118/3/35.ASP ) which documents 65,525 maximum clusters with a maximum of 32KB. Note that this is assuming the drive starts on the first head and sector of the cylinder, which generally involves wasting most of the first cylinder. By default, the first cylinder's sector is the MBR and the first partition starts on the (err... notes should be double-checked, and then values documented to replace the placeholders of X, Y, and Z in the following text) Xth track of the Yth head, resulting in less waste of the hard drive space but a first partition which is (some number of) bytes smaller. Since the space in a partition, and perhaps especially the first partition which is used to boot the drive, is more likely to be used, it may be better to start the partition after the start of this cylinder. This essentially wastes the small amount of disk space on the first cylinder, and is done to have a tiny amount more space where it may matter more.

More names

Wikipedia's article on File Alloation Table: section titled “Final FAT16” notes that the variation of FAT supported by Compaq Personal Computer DOS 3.31 (and newer, including MS-DOS 4) “was initially called the DOS 3.31 Large File System. Microsoft's DSKPROBE tool refers to type 0x06 as BigFAT, whereas some older versions of FDISK. describe it as BIGDOS. Technically, it is known as FAT16B.” (So, BigFAT, BIGDOS, and FAT16B are all names for the same thing, which is the variation of FAT16 which has been widely supported since November 1987's release of Compaq Personal Computer DOS 3.31.)

[#fat12]: FAT12

Microsoft KB Q69912: MS-DOS Partitioning Summary says, “MS-DOS began supporting hard disks in version 2.0.” “MS-DOS 2.x supports one type 01 partition of up to 15 megabytes (MB) in size, which uses a 12-bit file allocation table (FAT). Fdisk creates only one MS-DOS partition per drive.” The “type 01 partition” refers to the MBR partition type identifier byte having a value of 1. (Partition type identifiers are often rendered as dual-hex digits. This same partition type value is also documented by Microsoft KB Q69912: MS-DOS Partitioning Summary.) Newer operating systems support actively using more partitions per drive, but continue to use the same partition type identifier.

FAT12 is typically used for floppy disks.

[#parttyp1]: Partition type 01

If a FAT12 partition is on a hard drive, the MBR Partition Type Identifier for the FAT12 partition is 1.

Wikipedia's article on File Allocation Table (FAT): section titled “Final FAT16” says, “In practice however, type 0x01 and 0x04 primary partitions should not be physically located outside the first 32 MB of the disk, due to other restrictions in MS-DOS 2.x, which could not cope with them otherwise.”

Wikipedia's article on File Allocation Table (FAT): section titled “Initial FAT16” says, “MS-DOS 2.x hard disks larger than 15 MB are incompatible with later versions of MS-DOS.” (However, Wikipedia then cites Microsoft KB Q69912: MS-DOS Partitioning Summary, which does not actually say that. So, verify that before counting on it.

[#exfat64]: exFAT (a.k.a. FAT64)
Overview info

MSDN Windows Embedded Server documentation: FAT File System touts exFAT, and refers to MSDN Windows Embedded Server documentation: Transaction-Safe Extended FAT (“TexFAT”) File System.

Partition Type Identifier
7 (7h, 0x07) : This is the same as other filesystems that are commonly supported by “IFS” (installable filesystem) drivers: NTFS and HPFS.
Compatibility information

There is an option available that uses FUSE. exFAT code project, and some related reading: Announcement of fuse-exfat & exfat-utils 1.0.0 release announcement, Slashdot article: fuse-exfat 1.0 which would allow compatability when using FUSE, Phoronix article on exFAT/FUSE.

Windows XP SP2 (or SP3) and Windows Server 2003 SP1 (except SP2 may be needed for IA64) do not support this, but can with some freely available updates that Microsoft created. See: MS KB 955704, download details for exFAT driver.

Other variations
FAT8
Wikipedia's article on File Allocation Table (FAT): section on 8-bit FAT
FAT+
Wikipedia's article on File Allocation Table (FAT): section on FAT+
Some Non-PC variants

These have not been commonly used on personal computers.

FATX

Used by Microsoft's Xbox video game consoles. Free60 reference page about FATX says the header may be seen as XTAF (as a result of endianness), and the filesystem is sometimes referred to by that rendering of the header. Perhaps some of the following resources may be useful: (Some may need to use Wayback machine.) http://www.xbox-linux.org/wiki/Xbox_Partitioning_and_Filesystem_Details http://www.xbox-linux.org/wiki/Differences_between_Xbox_FATX_and_MS-DOS_FAT

Supporting devices include Microsoft's Xbox video game console system, Microsoft's Xbox 360 video game console system, and computers that use supporting Linux operating systems which do/may include the following: Xbox HD Maker (“XboxHDM”), Xebian http://www.xbox-linux.org/wiki/Xebian_HOWTO http://sourceforge.net/projects/xbox-linux/files/Ed_s%20Xebian/Xebian/ , GentooX.

TFAT
MSDN Windows Embedded Server documentation: Transaction-Safe Extended FAT (“TexFAT”) File System says “TexFAT replaces TFAT (Transaction-Safe FAT File System) in Windows Embedded CE 6.0.”

Note: These types of filesystems are also very often found within an extended partition. (If searching for all FAT filesystems, be sure to check for the presense of an extended partition.)

[#fatcmpat]: FAT's Compatibility
Traditional FAT's excellent compatibility

Perhaps the biggest benefit to using a FAT filesystem is that FAT12 and FAT16 have been the most compatible, supported filesystems for many years. Quite a bit of modern code that supports FAT12 and FAT16 will also support VFAT (which is discussed a bit further elsewhere in this text, and basically means supporting long filenames) and FAT32.

The most significant problems are the size limitations: FAT16 not being able to exceed 4GB (and 2GB in many cases) makes it unable to hold a single DVD image, and although a FAT32 partition can be larger, FAT32 also has a 4GB file size limit.

FAT also lacks certain features that some operating systems like, such as a common spot for storing information about security permissions for an individual account.

As long as those limits aren't a problem, FAT may be an excellent choice. Because those limits have seemed to impact people more (as network security has become more important over the years, and data sizes have grown), FAT compatibility might actually be decreasing a bit. (There seem to be a few more complaints with some newer versions of Microsoft Windows.) Still, for many years FAT was an extremely attractive choice for operating systems to support, and so compatibility with FAT was extremely wide-spread, and compatibility with FAT is likely to continue to be widely available.

In DOS, FAT is fully supported by key disk utilities, FORMAT (and, as needed, FDISK). (For more information about using that software, see the sections about making a filesystem (perhaps especially including the “making a filesystem” subsection on FORMAT requirements of an original sector), and also the section about handling disk layouts including the subsection about MBR-style disks.)

Linux/BSD typically supports mounting these drives using a format “type” called “vfat” and/or “msdos” and/or “fat”. This means that specifying the “type” (“ -t ”) parameter of certain software (designed to make a FAT filesystem or to test the filesystem) may use one of those words as a supported command line parameter. This also means that some executable names may have one of those “types” as part of the filename, such as fsck_msdos.

There is also MTools for Unix (MTools online manual) which may be able to manipulate a FAT partition without fully mounting it. For example, the documentation for the mbadblocks command says, “This command is intended to be used right after mformat. It is not intended to salvage data from bad disks.”

Note: Some software that handles partitions may often destroy the first disk sector of partitions, and especially FAT partitions, which may lead to data loss of all data on the filesystem. This may be a step that is not commonly needed with other software. For more details, see the documentation at: section about making a filesystem: subsection noting requirements of a partition's first sector and section about erasing a partition's first sector (clearing all of that sector's bits to have a value of zero).

[#vfat]: VFAT

This is somewhat less supported than pure FAT16.

VFAT
Overview/description

VFAT generally refers to the support of having LFNs (long filenames) on a FAT drive, using the method that ws implemented by Windows 95. MS KB 126855 does refer to “the Windows for Workgroups 3.11 32-bit file access (VFAT) feature”, which seems to be indicating that VFAT is a name that refers to using a 32-bit driver.

Compatability

This feature is basically built into FAT32 implementations (because VFAT was supported by Win95 OSR2 and Win98, which were the first FAT32 implementations). Popular “open source” support for FAT32 tends to also come with support VFAT for FAT16 and FAT12.

Support for VFAT was not included with MS-DOS, although there have been some drivers released to provide such support for MS-DOS and/or similar operating systems. Solutions may include DOSLFN (FreeDOS page for DOS LFN, LFNDOS (version 1.06, over a decade old, not open source), another LFNDOS which is open source (according to TLDP documentation on a Free LFNDOS driver). The TLDP documentation indications that this was once at http://members.xoom.com/dosuser/ and available as lfnds106.zip from the old Simltel.net archives.

For VFAT from OS/2, a GPL package called VFAT-OS2 has been made. See: VFAT-OS2.

ExFAT

Support for this came after many people started using filesystem types other than FAT (Ext2, NTFS, etc.) The exFAT file system: Can be supported by Win XP SP2 and SP3 for x86, XP for x64, Win Svr 2003 SP1 and SP2 for IA64, and Svr 2003 for x64, by getting downloadable files which may be obtained from Microsoft KB 955704: exFAT file system driver update package. Users of Windows XP Service Pack 3 who (probably currently have, and who) want to use the Multilingual User Interface set to a language other than English should read the bottom portion of KB 955704.

Other variations

The most widely supported method of storing long filenames on a FAT16 (or FAT12) drive is probably to use VFAT. Other methods have existed.

UMSDOS
UMSDOS supported long filenames and Linux permittions in a file called “--linux-.---” (stored in whatever directory the other files were stored in). A driver for this existed for Linux, although at some point of time support was dropped for a newer Linux kernel.
OS/2
OS/2 could support HPFS-style long filenames and OS/2 extended attributes in “\ea data. sf” (and “\wp root. sf”, according to TLDP documentation on OS/2 Extended Attributes on FAT). The “ea” in that filename surely referred to “extended attributes”.
Star LFN
Star LFN for DOS supported long filenames, perhaps in a way different than VFAT. TLDP documentation on Star LFN says “can only read and write long filenames from and into a system+hidden file”.
More
Wikipedia's article on File Allocation Table (FAT): section titled “Logical sector FAT” says, “Since older DOS versions were not flexible enough to work with these logical geometries, the OEMs had to introduce new partition IDs for their FAT variants in order to hide them from off-the-shelf issues of MS-DOS and PC DOS. Known partition IDs for logical sectored FATs include: 0x08 (Commodore MS-DOS 3.x), 0x11 (Leading Edge MS-DOS 3.x), 0x14 (AST MS-DOS 3.x), 0x24 (NEC MS-DOS 3.30), 0x56 (AT&T MS-DOS 3.x), 0xE5 (Tandy MS-DOS), 0xF2 (Sperry IT MS-DOS 3.x, Unisys MS-DOS 3.3 also used by Digital Research DOS Plus 2.1).” Reading through the entire Wikipedia article on FAT, it looks like these variations were newer than partition type 4, but before Microsoft standardized improvements with partition type 6. Wikipedia's partition ID list provides descriptions.
[#fatclusz]: Allocation Unit sizes: FAT Cluster Sizes

In FAT, an allocation unit is called a cluster. (On the hardware side, an allocation unit may be called a disk sector. However, all file fragments take up at least one cluster. Each cluster is the same size and takes up at least one disk sector.)

In general, smaller cluster sizes are usually nicer (as long as there aren't so many that the overhead of tracking so many clusters outweighs the advantage of a small cluster size). Microsoft KB Q140365: Default cluster size for filesystem formats commonly used on hard drives mentions that the amount of space lost is, on average, half of the cluster size multipled by how many files are on the filesystem.

The simple rule of thumb is that if a partition size is going to have a number of megabytes which is approximately equal to a power of two, make the partition slightly smaller than a power of two. Being even one sector smaller may result in a smaller allocation unit size, and this generally ends up resulting in more space being saved overall.

Microsoft KB Q67321:FAT Type and Cluster Size Depends on Logical Drive Size (MS-DOS FAT12/FAT16), and which notes “In the past, some OEMs have modified their versions of MS-DOS to support other sector and/or cluster sizes.” So there may be some historical code that was sold commercially which varies a bit from the information provided in the rest of this section. It is also possible that some implementations (perhaps made with Linux software?) might create a filesystem which isn't fully compatible with MS-DOS. Generally, when using FAT12 and FAT16, using a filesystem compatible with MS-DOS is recommended for compatibility with not just that operating system, but also most other supporting software.

In addition to some of the references already provided, here are some other resources kindly provided by Microsoft: Microsoft KB Q69912: MS-DOS Partitioning Summary (for old DOS history). Perhaps related: KB Microsoft KB Q118335: Maximum Partition Size Using FAT16 File System (mentions NT 4GB FAT), TechNet: FAT16 vs. FAT32, Microsoft KB Q192322: FAT32 Cluster Sizes

Creating FAT filesystems

The relevant information to create a FAT drive should be readily available by reviewing the details about making a filesystem (including the “making a filesystem” subsection about FORMAT requirements of an original sector) and the details that are documented in the FAT Compatibility section. Note that choosing a particular format and/or may help result in smaller FAT cluster sizes, and this reduction in allocation unit size may often lead to an increase of available disk space (in the short term, and slightly more down the road as more files are added).

Testing/Repairing FAT filesystems
Testing

Testing FAT may be supported by internal tools described by the section on testing/repairing filesystems. Note that it is recommended to test using read-only in certain situations, such as if the drive is in use by Microsoft Windows or if using an operating system that is not recommended for repairing FAT filesystems. In addition to whatever is supplied by the operating system, another option is the mtools package which has an mbadblocks command. (A graphical interface for mtools may be available using MToolsFM.sf.net's software which uses the GPL.)

[#fatfsrpa]: Repairing FAT filesystems

For repairing FAT, some commonly given advice (although perhaps it is very old and should be considered obsolete) is to use specialized software designed to be run from a version of DOS or Microsoft Windows. This may be inconvenient (especially if it involves bringing down a server to reboot to another operating system), but note that if there are known issues with the filesystem volume, taking time to correct the issue is likely worthwhile (especially for systems that use hardware capable of running 16-bit DOS code). See checking filesystems in DOS and/or checking filesystems in Microsoft Windows.

[#fatrcovr]: Data recovery on FAT drives

This section contains some of the details specific to the FAT file format. For more information about recovering data, including warnings and other details that may help recovery be more likely to succeed, also be familiar with data recovery basics. There are some common warnings/approaches to take which should be followed (but which, to minimize redundancy, are not duplicated here.)

Undeleting files
FAT12/FAT16

The Unerase??? from DR-DOS (and/or related software: OpenDOS, DR-OpenDOS, Novell DOS) may restore a file, including the filename by using data stored on a second copy of the FAT.

MS-DOS version 5? version 6? comes with Undelete which loses the first character of the filename. This is because of two reasons: the first character of the filename is erased when the file is deleted, and this software was not designed to locate a copy of that first character stored elsewhere on the hard drive.

Other options may include TestDisk (discussed in sections about other file systems: see Disaster Recovery?), and Piriform's Recuva (which has a free download available).

For OS/2, perhaps at least some software that handles undeleting files from HPFS might also have support for FAT.

FAT 12/16/32, VFAT

Official guide to using TestDisk to undelete from FAT.

ExFAT

Official guide to using TestDisk to undelete from FAT.

The Unformat and Mirror commands

Some versions of DOS may come with an Unformat command. Do not take any comfort from the presense of this command. Some details may be available from Microsoft KB Q69767: Information on MS-DOS FORMAT, UNFORMAT, and MIRROR Utilities. That document notes, “NOTE: MIRROR does not come with Microsoft MS-DOS 6.0, 6.2, or 6.21.” However, it may be available as part of a downloadable disk of MS-DOS supplemental software. See: TOOGAM's Software Archive: Page about MS-DOS (section about MS-DOS Supplemental Disks). MIRROR documentation

Recover
There is a reason why Rick's comment describes this command as “brain dead Microsoft behavior”. Before relying on this program (and ruining your whole hard drive), read about this atrocity at Wikipedia's article on MS-DOS's Recover command
[#fatdefrg]: Defragmenting FAT

Many people have had misconceptions about defragmenting, such as believing that defragmenting will often fix something that isn't functioning successfully. In reality, defragmenting is mainly about trying to speed up access to data, with possible side effects of reducing “wear and tear” on equipment. Handling data: section on Defragmenting discusses defragmenting in general.

Various versions of DOS and Microsoft Windows may come with defragmentation software. Try running DEFRAG. More specifically, it is common that a single drive letter may be referenced on the command line, using a syntax such as “ DEFRAG C: ”.

In DR-DOS, the command may be DiskOpt.

For exFAT, see UltraDefrag (mentioned in the section about tools for Microsoft Windows).

More defragmenting programs available for Microsoft Windows

In Microsoft Windows, you can run “Defrag /?”. In addition to that command designed for usage from the commadn line, there may also be an MMC snap-in. Wikipedia's article on Defragmentation: “Approach and defragmenters by file-system type” section indicates that for Windows 2000, XP, and 2003, this may be based on code licensed by Diskeeper. MSDN: Disk Defragmenter for FAT.

Forum post about defrag noted, “I've found that XP and Windows Server 2003 need about three passes of the defragmenter to do a really good job.” (Hmm... if that is fairly accurate, then it would be rather sad that the program would quit twice, indicating success, when there is more work to be done in order to optimally accomplish its primary purpose.) Using a command to gather some statistics/info may help to determine how useful a completed defragmentation attempt was, and might even help to determine ahead of time how useful a future defragmentation attempt might be. A way to gather this information is to run a command such as:

defrag -a c:
XDefrag

For Microsoft Windows, there is a helper application that can be downloaded: see Home page for XDefrag.vbs. Perhaps see also: XDefrag version 1.0 which, according to its comments, requires Windows XP or newer.

Key features include an easy ability to get the results report placed into the Windows Event Logs, and having a paramter that can cause all local drives to be defragmented. (That parameter may be useful to allow a single command to be usable on multiple machines without needing to try to customize the command for each machine.)

UltraDefrag

UltraDefrag (UltraDefrag project page) provides upport for FAT, including exFAT (and also supports NTFS). Version 6.0.2 was documented to work in Windows NT 4.0, 2000, XP, and newer versions (2003, Vista, 2008, 7, 2008 R2, 2012 and 8). At the time of this writing, version 7 was expected to drop support for Windows NT 4.

Questionable future

The software's main home page (@ http://ultradefrag.sf.net) has been known to prominently show the lastest news article, which, for months (at least), was UltraDefrag's latest news of 2016 update which had some unpleasant aspects.

The post started out stating “nine months passed since the last release and we're still not making any significant progress towards the next milestone.” The provided reasons seemed to do more with struggles that were not really related to the software other than the consideration that these struggles were experienced by the software's developers.

The post also seemed to mention a situation affecting the deveopers personally. It stated, “we expect time and a bit of money still could help us to get out of hell. Overall we need about $35K to move away to a place where nothing will remind us about horrible things we've passed through.”

The news post was signed by “Dmitri Arkhangelski” “UltraDefrag Chief Architect”. The post was rather unclear about just what tragedy befell the poeple, except “it's never easy to keep things going when people you love die”.

At the time of this writing, in March 25 of 2017, this post seems to leave the future of this software in doubt. However, the December 17, 2016 post does say, “In the last 9 months we've managed to collect over $4000” And, at the time of this writing, the fundraiser reporter shown on the software's main home page (@ http://ultradefrag.sf.net) shows “$6625 collected towards $35000”.

A picture, shown in the upper-left corner of a web page for the program's handbook (e.g., UltraDefrag Handbook: Console Interface), showed colors for the letters: “ Ultra Defrag

MyDefrag / JKDefrag

JKDefrag was released as open source. JKDefrag is old, and has been replaced with MyDefrag. MyDefrag has been discontinued, as mentioned by Wikipedia's article on MyDefrag.