What is an allocation unit (cluster size) in file systems?

An allocation unit or cluster is the smallest discrete block of disk space that an operating system can allocate to hold a file. Even if a file contains only 1 byte of data, the filesystem reserves at least one complete cluster on disk.

What causes slack space waste and internal fragmentation?

Slack space occurs because files rarely match cluster size multiples exactly. The unused portion of the final allocated cluster cannot be shared with another file. On average, each file wastes half of one cluster (Cluster Size / 2), which accumulates into gigabytes across millions of files.

Why is 4 KB (4096 bytes) the default cluster size for NTFS and ext4?

4 KB matches the virtual memory page size of modern x86/x64 processors and disk drive physical sectors (Advanced Format 4Kn/512e). This alignment ensures zero read-modify-write translation penalties and maintains a healthy balance between slack space waste and file metadata overhead.

When should you use large 64 KB or 128 KB cluster sizes?

Large cluster sizes (64 KB to 2 MB) are recommended for dedicated media drives, SQL Server databases, video editing scratch disks, and virtual machine LUNs where files are gigabytes in size. Larger clusters reduce Master File Table (MFT) extents and improve sequential I/O transfer speeds.

How does filesystem metadata like NTFS MFT and ext4 inodes affect capacity?

Each file requires dedicated metadata entries regardless of its payload. NTFS allocates 1,024 bytes per file in the Master File Table ($MFT), while ext4 allocates 256 bytes per inode. Directories with millions of tiny files can easily consume 500 MB to 2 GB solely in filesystem indexing structures.

Cluster Size Calculator: NTFS & Slack Space

File System Cluster Sizes and Slack Space Architecture

Every modern file system—whether Microsoft NTFS, Linux ext4/XFS, or cross-platform exFAT—organizes physical storage sectors into logical allocation units known as clusters. When an operating system writes a file to storage, it does not allocate raw individual bytes; rather, it reserves whole discrete clusters. Understanding this mechanism is vital for avoiding massive storage waste and eliminating system I/O bottlenecks.

What is Internal Fragmentation and Slack Space?

Internal fragmentation is the technical term for unusable free space trapped inside an allocated disk cluster. Because files rarely match an exact multiple of the cluster size, the final cluster assigned to a file is almost always only partially filled. The remainder of that cluster cannot be shared with or allocated to any other file.

For a random distribution of file sizes, the average unused slack space per file asymptotically approaches exactly half of the cluster size:

Average Slack Space Per File = Cluster Size (Bytes) / 2
Total Volume Slack Waste = Total File Count × ( (⌈File Size / Cluster Size⌉ × Cluster Size) - File Size )

While losing an average of 2 KB per file on a standard 4 KB NTFS cluster may appear negligible for a single document, in environments with hundreds of thousands of files—such as web server caches, software developer repositories (node_modules), git repositories, or microservice log directories—internal slack space easily wastes tens to hundreds of gigabytes of drive capacity.

Why 4 KB is the Industry Standard Default

The 4,096-byte (4 KB) allocation unit has been the worldwide industry default for decades for several compelling architectural reasons:

CPU Memory Page Alignment: The virtual memory management subsystem on x86, AMD64, and ARM processors operates on 4 KB physical memory pages. Matching file system clusters to memory pages eliminates CPU translation overhead during file paging and memory-mapped file I/O (mmap).
Advanced Format (4Kn / 512e) Drive Alignment: Physical magnetic hard drives and modern NVMe SSDs utilize native 4 KB physical flash blocks/sectors. Aligning file system writes to 4 KB boundaries avoids catastrophic "Read-Modify-Write" penalty cycles.
Balanced Space Efficiency: At 4 KB, the average slack loss of 2 KB per file represents an acceptable compromise between metadata complexity and space conservation for standard desktop and server operating systems.

When to Choose Larger Cluster Sizes (16 KB to 64 KB+)

Formatting volumes with allocation units larger than 4 KB provides substantial performance gains under specific, large-file workloads:

Microsoft SQL Server & Database LUNs: Microsoft formally recommends a 64 KB allocation unit for SQL Server data and log files. SQL Server reads and writes in 64 KB extents (eight contiguous 8 KB pages). Aligning the filesystem cluster size to 64 KB ensures that extent reads occur as single atomic filesystem operations.
Video Production & Streaming Media: For drives dedicated to 4K/8K video editing, raw audio recordings, or high-capacity backup archives, average file sizes exceed hundreds of megabytes. A 64 KB or 128 KB cluster size drastically reduces filesystem fragmentation, shrinks Master File Table overhead, and accelerates sequential throughput.
Virtual Machine Disk Stores (VMFS / VHDX): Virtual disk image containers are massive monolithic files. Large cluster sizes minimize metadata tracking requirements across the host storage array.

Filesystem Metadata Overhead: NTFS MFT and ext4 Inodes

In addition to cluster slack, file systems require structural indexing tables:

NTFS Master File Table ($MFT): NTFS allocates a 1,024-byte record in the $MFT for every single file and folder. Files with extensive attribute lists or heavy fragmentation require additional extension records.
ext4 Inodes: The Linux ext4 filesystem allocates 256 bytes per file for inode metadata. By default during formatting (mkfs.ext4), ext4 reserves approximately 1.5% to 5% of the total disk partition capacity exclusively for inodes.

Frequently Asked Questions

"Size" represents the actual logical byte count of the data inside your files. "Size on Disk" represents the physical storage space reserved by the file system, which consists of whole clusters plus cluster slack space and filesystem compression or sparse file attributes. "Size on Disk" is almost always larger than "Size".

Native operating system tools like Windows Disk Management or Linux fdisk cannot alter the cluster size of an active partition without formatting the drive and erasing all data. Some third-party partition managers offer non-destructive cluster size conversion, but standard best practice is to back up data, reformat with the desired allocation unit, and restore files.

No. Microsoft NTFS native file compression is strictly supported only on volumes formatted with cluster sizes of 4,096 bytes (4 KB) or smaller. If you format an NTFS volume with 8 KB, 16 KB, or 64 KB clusters, Windows completely disables built-in NTFS compression for that drive.

NTFS features an optimization known as "resident files." If a file and its attributes are small enough (typically under 700 to 800 bytes), NTFS stores the entire file payload directly inside the 1,024-byte Master File Table ($MFT) record itself. In this specific scenario, zero data clusters are allocated on the drive, eliminating slack space for tiny files.

On NTFS, a 4 KB cluster size supports volumes up to 16 Terabytes using standard formatting, and up to 256 Terabytes on Windows Server with GPT partition tables. Formatting with larger cluster sizes (e.g. 64 KB) allows NTFS to support single volumes up to 2 Petabytes.

Cluster Size & Slack Space Calculator

Storage Volume & Workload Parameters

Cluster Storage Footprint