Filesystem Shootout: Slim64FS vs FAT32 vs exFAT vs ext2

Purpose: Compare Slim64FS against the three filesystems it most directly competes with or replaces on removable flash media.

Key: ✅ Winner (best in group) · ❌ Worst in group · — Neutral / not applicable

Volume Capacity

Notes:

• FAT32 is capped at 2 TiB with 32 KiB clusters (Microsoft official limit); many implementations cap lower.
• exFAT uses 64-bit cluster count → 128 PiB theoretical.
• ext2 tops out at ~32 TiB with 4 KiB blocks (32-bit block addresses).
• Slim64FS supports 8 EiB (64-bit Linux off_t ceiling) — sufficient for any foreseeable flash media.

File Size

¹ Contiguous file can fill the volume. Maximally fragmented file (258 single-block extents) is limited to ~1 MiB — see Fragmentation row.

Notes:

• FAT32's 4 GiB limit is a hard format constraint (32-bit file size field). A 4K RAW file from a modern camera is ~50 MB; a 1-hour 8K video is 100–400 GB — FAT32 cannot hold it in a single file.
• exFAT removes this limit entirely.
• ext2 uses 32-bit block pointers; with 4 KiB blocks and triple-indirect addressing, max is ~2 TiB.

Fragmentation Tolerance

Notes:

• Slim64FS caps extents at 258. A highly fragmented file cannot grow beyond 258 extents. This is a deliberate trade-off: the extent map fits in the inode's reserved region + one overflow block, enabling O(1) inode reads.
• For camera workloads (sequential large-file writes to freshly formatted media), fragmentation rarely exceeds single-digit extents. The 258 cap is never reached in practice.
• FAT32, exFAT, and ext2 follow chains of arbitrary length — correct but slower for highly fragmented volumes.

Filename Length

Notes:

• All four are equivalent at 255 characters for ASCII. FAT32/exFAT use UTF-16 (Windows default), meaning some Unicode characters count as 2 code units; certain emoji filenames can be shorter than 255 characters. Slim64FS and ext2 are byte-length based.

Directory Depth

¹ Windows Explorer imposes a practical ~32-level limit due to PATH_MAX; the FAT/exFAT format itself has no depth limit.

Notes:

• Slim64FS deliberately caps directory depth at 16. This enforces O(1) path traversal depth and prevents runaway nesting, which can be a denial-of-service vector on embedded systems.
• For camera/photography use, directory depth rarely exceeds 5 (e.g., DCIM/100CANON/IMG_1234.CR3).

Integrity / Error Detection

Notes:

• FAT32 has zero checksum coverage. Silent bit rot produces corrupt data with no detection.
• exFAT adds a checksum only to the boot region; directory entries and file data are unprotected.
• ext2 has optional metadata checksums (disabled by default); ext4 enables them by default.
• Slim64FS checksums all metadata structures on every commit. CRC32C is hardware-accelerated on all modern x86 (SSE4.2) and ARM (ARMv8-A) CPUs — it is effectively free.

Crash Safety / Durability

Notes:

• FAT32: a power loss during a FAT update leaves the volume in an inconsistent state with no self-healing.
• exFAT: similar to FAT32; relies on the host OS to handle dirty-volume recovery; no guaranteed atomic commit.
• ext2: requires fsck after unclean shutdown; no journal (ext3/ext4 add journaling).
• Slim64FS uses CRC-verified dual-slot commits. The most recent valid committed generation always wins on mount. Power loss during a checkpoint is detected (CRC mismatch on the in-progress slot) and the previous checkpoint is restored.

Hard Links

Notes:

• Hard links are not supported on FAT32 or exFAT at all.
• ext2 supports hard links fully (nlink tracked per inode).
• Slim64FS returns EOPNOTSUPP for link() calls. This is a deliberate trade-off: supporting hard links would require converting the namespace from a tree to a DAG, complicating the dirlog recovery invariants. Camera workloads do not use hard links.

Symbolic Links

POSIX Permissions

Notes:

• FAT32 and exFAT have no concept of ownership or permissions — every file is readable and writable by everyone. This is fine for removable media passed between systems; it is unacceptable for a multi-user server.
• Slim64FS stores full POSIX uid/gid/mode, enforced at mount by the kernel (default_permissions, always on since V14.1); ACLs are not implemented.
• ext2 implements full POSIX permissions plus optional ACL support.

Timestamp Precision

Notes:

• FAT32 stores mtime at 2-second granularity (a legacy from MS-DOS). Sub-second timestamps are inaccessible.
• exFAT improves to 10ms precision — useful for burst photography workflows where multiple files share the same second.
• Slim64FS and ext2 provide 1-second precision.
• FAT32 and exFAT both have a year-2107 hard wall (32-bit timestamp fields). Slim64FS uses uint64_t seconds — effectively unlimited.

Compression / Encryption

Notes:

• None of these filesystems implement compression or encryption natively. (ext4 adds encryption; not ext2.)
• Slim64FS deliberately excludes both: target media (JPEG, MP4, RAW) is already compressed; encryption is out of scope for an integrity-focused filesystem.

License / Patent Status

Target Use Case Fit

Summary Scorecard

Reading the scorecard: Slim64FS wins on the properties that matter most for camera-class removable flash — crash safety, integrity, license freedom, and (since V14.1) full, kernel-enforced POSIX permissions. Its single ❌ (hard links) is irrelevant to the target use case. FAT32's 8 ❌ marks reflect its age; it persists purely through universal hardware support. exFAT wins on raw capacity but lacks integrity and crash safety. ext2 shares the permissions win (adding ACLs) but was designed for spinning disk, not flash.