FAT: Explanation & Insights

The filesystem everything on earth can read, doing the one job a server filesystem should never do.

What It Is

FAT stands for File Allocation Table, and unlike most acronyms in this field it names the exact thing that makes it tick: a literal table, sitting near the front of the disk, that records which pieces of storage belong to which file. It was born in 1977 for floppy disks, grew up through MS-DOS and Windows, and somehow — decades after the technology that spawned it became a museum piece — it is still, today, the most universally understood filesystem on the planet. Every operating system reads it. Every camera writes it. The chip in your car's infotainment system, the firmware loader on your motherboard, the SD card in a drone — all FAT. It is the Latin of storage: nobody's first choice, everybody's common tongue.

If you're coming from writing software, you may have only ever met FAT as "the format my USB stick came in," and never wondered why. The short version is that FAT trades away almost everything a serious filesystem offers — permissions, journaling, symlinks, large files — in exchange for one quality so valuable it outweighs all of those: anything can read it. That trade is either perfect or catastrophic depending entirely on what you point it at, and untangling when it's which is the whole point of this page.

On Linux you rarely interact with FAT under its own name. The kernel reads it through a driver called vfat, and you'll almost always mount it with -t vfat. So treat this page as the concept — the family, the table, the philosophy — and its sibling vfat page as the driver you actually type.

The FAT Family

"FAT" isn't one filesystem; it's a small family that grew as disks grew, and the number in each name tells you how many bits wide the table entries are — which in turn caps how many allocation units the filesystem can address.

FAT12 — 12-bit entries, the floppy-disk original. You'll never format one on purpose, but it's still what a 1.44 MB floppy image uses, and the occasional ancient embedded device.
FAT16 — 16-bit entries. The hard-disk filesystem of the early 1990s, capped at small volumes. Effectively retired; you'll only meet it on tiny flash media or legacy gear.
FAT32 — 32-bit entries (well, 28 in practice), introduced in 1996. This is the FAT you actually use today: USB sticks, SD cards, and — crucially — the EFI System Partition that boots modern machines. When someone says "format it FAT," they mean FAT32.
exFAT — not technically FAT at all, but the family's modern cousin: a Microsoft design from 2006 that keeps FAT's simplicity and universal-interchange spirit while dropping the 4 GiB-per-file ceiling. It's what large SDXC cards (64 GB and up) ship with. Linux has had solid in-kernel exFAT support since 5.4 (2019). It is not the same driver as vfat — you mount it as -t exfat — but philosophically it belongs in the same drawer: a lingua-franca filesystem for removable media, never a server's root.

The headline limit you must remember is FAT32's: no single file may exceed 4 GiB (one byte short of 4 GiB, in fact — the size field is 32 bits). Try to copy a 5 GB video onto a FAT32 stick and the copy fails partway with a baffling error. That single number is why exFAT exists and why every "why won't my big file copy" support thread eventually arrives at the same answer.

How the Table Actually Works

Here's the part worth slowing down for, because it's a small, self-contained idea you can hold entirely in your head — and once you have, the name "File Allocation Table" stops being jargon and becomes a description.

The disk is carved into fixed-size lumps called clusters (FAT calls them clusters; other filesystems say blocks). A cluster might be 4 KB, or 32 KB on a big FAT32 volume — pick a size at format time. A file that's bigger than one cluster has to be stored across several, and the clusters a file lands in are usually not next to each other. So how does the system know, having read cluster 17, which cluster comes next?

It looks it up in the table. The File Allocation Table is one big array, with one slot per cluster on the disk. The value in each slot is the number of the next cluster in the chain — or a special marker meaning "this is the last one." It is, in the purest sense, a singly linked list, except the "next" pointers don't live inside the data; they're all pulled out and stacked together in one table at the start of the disk.

Directory entry "movie.mp4" → starts at cluster 17

Table:  cluster 17 → 18
        cluster 18 → 25      (gap! 19–24 belong to other files)
        cluster 25 → 26
        cluster 26 → EOF     (end of chain)

So movie.mp4 lives in clusters 17, 18, 25, 26 — follow the links.

To read the file you find its starting cluster (recorded in the directory entry), read that cluster, then ask the table where to go next, and follow the chain link by link until you hit the end-of-file marker. To find free space you scan the table for slots marked 0 (unused). To delete a file you walk its chain marking each slot free. Everything — allocation, deletion, the whole map of the disk — is that one table. It's the kind of design you could explain to a clever twelve-year-old in five minutes, and that very simplicity is exactly why a microcontroller with a few kilobytes of RAM can implement it. There's a reason it conquered the world.

It also explains FAT's oldest complaint: fragmentation. Nothing forces a file's clusters to be contiguous, and as you create and delete files the free clusters scatter, so new files get sprinkled wherever space happens to be. On spinning disks this meant the head physically seeking back and forth to read one file — hence the ritual "defragmenting" of the Windows era. On flash (where every cluster is equally fast to reach) it barely matters, which is convenient, because flash is where FAT actually lives now.

What It Doesn't Have

A server admin's first instinct should be suspicion, so let's be blunt about everything FAT lacks — because the absences are the whole reason it's wrong for server data.

No permissions. FAT has no concept of an owner, a group, or read/write/execute bits. A file is just a file. There's no way to say "only this user may read this." For a multi-user server this is disqualifying on its own. (Linux fakes ownership at mount time with uid=/gid=/umask= options — more on that in the vfat page — but it's a costume, not a permission system. The disk stores nothing.)
No journaling. When you change a file, FAT updates the data, the table, and the directory entry as separate steps with no transaction wrapping them. Lose power in the middle and the on-disk structure is now inconsistent — a chain pointing into space, a cluster claimed by two files. There's no journal to replay; recovery means a full scan with fsck and crossed fingers. This is the single biggest reason FAT corrupts.
No symlinks, no hard links. The directory-to-chain model has no room for two names pointing at one file, nor for a symbolic redirect. The whole Unix tradition of linking is simply absent.
No large files. The 4 GiB-per-file ceiling on FAT32, covered above.
No checksums. FAT can't detect silent corruption; a flipped bit just becomes wrong data, quietly.

Danger

Never put a server's root or data filesystem on FAT. With no permissions every file is world-accessible, with no journaling an unclean shutdown can scramble the structure, and with no symlinks half of a normal Linux install simply can't be represented. Use ext4 or XFS for anything the server actually runs on.

Why FAT Is Everywhere — and Why That's Correct

Here's the bit that confuses people, and the bit worth getting straight, because it's easy to read the list above and conclude FAT is just bad. It isn't. It's specialised — and the thing it specialises in is genuinely the most important property a removable or interchange filesystem can have: everything can read it.

Think about what an SD card has to do. You write photos to it in a camera made by one company, then pull it out and read it on a laptop made by another, running an OS made by a third, then hand it to a friend whose phone runs something else entirely. There is no negotiation, no driver install, no "please update your software." It just works, across every device on earth, because they all speak FAT. A "better" filesystem with permissions and journaling and checksums would be useless here, because the camera's firmware would have no idea how to read it. FAT's job description isn't "be safe" or "be fast" — it's "be understood by a device you've never heard of, built before yours existed." At that job it has no equal.

And then there's the one place FAT shows up on a Linux server, by law: the EFI System Partition (ESP). When a modern machine boots via UEFI, the firmware — running before any operating system exists — needs to read the bootloader off the disk. The firmware is a tiny program baked into a chip by the motherboard maker, and the UEFI specification mandates that it understands exactly one filesystem so that every disk is bootable on every machine. That filesystem is FAT (FAT32 on real disks). So the small /boot/efi partition on essentially every UEFI Linux box is FAT32 — and it should be. It's not a compromise or a leftover; it's the spec working as intended. The firmware can't be expected to ship an ext4 driver, so the bootloader lives on the one filesystem the firmware is guaranteed to read.

Note

The two correct uses of FAT on a Linux machine are removable media you'll move between devices, and the ESP that UEFI firmware reads at boot. Both are about interoperability with software you don't control — the camera, the firmware. For anything the Linux server controls end to end, FAT has no advantage and several serious drawbacks.

So the rule is simple and worth memorising: FAT for the ESP and for things that leave the building; a real filesystem for everything else.

How I Inspect It

You don't manage FAT volumes the way you manage a server's root — you mostly check what's there and confirm it's healthy. Three commands cover it.

lsblk -f shows you, in one tree, which partition is FAT and where it's mounted — the ESP stands out immediately:

lsblk -f

NAME   FSTYPE FSVER LABEL UUID                                 MOUNTPOINTS
sda
├─sda1 vfat   FAT32       ABCD-1234                            /boot/efi
├─sda2 ext4   1.0         a1b2c3d4-e5f6-7890-abcd-ef1234567890 /
└─sda3 swap   1           12345678-...                         [SWAP]

Note the blkid detail worth knowing: a FAT "UUID" like ABCD-1234 is not a real UUID. FAT has no field for one, so Linux synthesises an 8-hex-digit identifier from the volume's serial number — short, and only probably unique. It's still what you reference in /etc/fstab, but don't expect the long random string you'd see on ext4.

df -hT confirms the type and how full it is — the ESP is tiny and should stay nearly empty:

df -hT /boot/efi

Filesystem     Type  Size  Used Avail Use% Mounted on
/dev/sda1      vfat  511M  5.3M  506M   2% /boot/efi

And blkid gives you the type and that pseudo-UUID for a single device when you're editing /etc/fstab.

Cheat Sheet

The moves you'll actually make. Note that the creation and repair tools are named after vfat/fat/dos, not "fat" — a small naming quirk that trips people up:

# --- Identify ---
lsblk -f                          # which partition is FAT, where it's mounted
blkid /dev/sda1                   # type + pseudo-UUID for one device
df -hT /boot/efi                  # size and usage of the ESP

# --- Create ---
mkfs.vfat -F 32 /dev/sdb1         # FAT32 (mkfs.fat is the same binary)
mkfs.fat -F 16 /dev/sdb1          # FAT16, for tiny media
mkfs.vfat -n MYSTICK /dev/sdb1    # with a volume label

# --- Check / repair (always on an UNMOUNTED device) ---
fsck.vfat -a /dev/sdb1            # auto-fix what's safely fixable
dosfsck -v /dev/sdb1             # same tool, classic name, verbose

# --- Mount (Linux uses the vfat driver) ---
mount -t vfat /dev/sdb1 /mnt/stick

Pro Tip

mkfs.vfat, mkfs.fat, fsck.vfat, and dosfsck are not four programs — they're two programs wearing four names (the dosfstools package). mkfs.vfat is mkfs.fat; dosfsck is fsck.vfat. Use whichever name you remember; they do exactly the same thing.

History and Philosophy

FAT's age is genuinely startling. The original 8-bit table was sketched by Bill Gates and Marc McDonald in 1977 for Microsoft's Standalone Disk BASIC, before MS-DOS existed — making FAT older than the IBM PC, older than the Macintosh, older than the internet as anyone uses the word. It then rode MS-DOS and Windows to total market dominance through the 1980s and 90s, and when the world needed a format that everything could read, FAT was simply already there, already in every device. Ubiquity begat ubiquity.

The deeper lesson FAT teaches is about the cost and value of simplicity. A filesystem you can implement in a few kilobytes, that a manufacturer can drop into firmware without licensing a complex codebase or shipping a driver, is a filesystem that ends up everywhere — and being everywhere is itself a feature no amount of cleverness can buy. FAT is mediocre at nearly everything and unbeatable at the one thing that turned out to matter most for removable media. It's a reminder that "best" is always "best for what," and that the humble, unfashionable tool is sometimes the one quietly holding the whole world together. There is, after all, a copy of FAT32 sitting on the boot partition of the very machine running your shiny ZFS array — and it got there because it earned it.

For the Linux-specific story — how the kernel reads FAT, the long-filename trick layered on top, and a tidy little patent saga — see the vfat page.