Cluster (Allocation Unit)
A cluster is the smallest unit of disk space a file system can allocate. Even a 1-byte file consumes one full cluster. Clusters group multiple sectors together to reduce metadata overhead: tracking 250 million 4 KB clusters is more practical than tracking 2 billion 512-byte sectors. Cluster size shapes everything from wasted space (small files in big clusters) to performance (IO amplification when writes are smaller than the cluster) to recovery (clusters are the basic unit of file reconstruction). The 4 KB default has been stable for two decades; larger clusters appear in specialized configurations.
HowToGeek · ScienceDirect
For partitions > 2 GB
Advanced Format era
A cluster (also called an “allocation unit” on Windows or a “block” on Unix-like systems) is a contiguous group of disk sectors that a file system treats as a single allocation unit. The cluster is the smallest unit of disk space the file system can allocate to a file; even a 1-byte file consumes one full cluster’s worth of disk space. Clusters exist to reduce the metadata overhead of tracking which sectors hold which files; standard cluster sizes are 4 KB (default for most modern file systems), 8 KB, 16 KB, 32 KB, and 64 KB. Different file systems use different terms for the same concept: NTFS calls them clusters, the ext family calls them blocks, HFS+/APFS call them allocation blocks.
What a Cluster Is
The Microsoft TechCommunity ReFS and NTFS cluster size documentation captures the foundational definition: “Microsoft’s file systems organize storage devices based on cluster size. Also known as the allocation unit size, cluster size represents the smallest amount of disk space that can be allocated to hold a file. Because ReFS and NTFS don’t reference files at a byte granularity, the cluster size is the smallest unit of size that each file system can reference when accessing storage.”1
Why clusters exist
The fundamental design rationale is metadata efficiency. A 1 TB drive contains roughly 2 billion 512-byte sectors or 250 million 4 KB sectors; tracking allocation per-sector would require enormous bitmaps and complex metadata structures. By grouping sectors into clusters, the file system reduces the number of allocation units it must track, simplifying both the allocation bitmap and the per-file pointer arrays. Clusters are an abstraction layer that trades some space efficiency for substantially simpler and faster metadata management; the tradeoff is generally favorable for typical file sizes.
Each file consumes whole clusters
The HowToGeek allocation unit guide describes the consumption model: “If a file is too big to fit in a single block, then it will be split and span multiple blocks. If a file is smaller than the block size, then it will be stored in that block, but the entire block volume will be used up.” This rule has consequences:
- A 100-byte file in a 4 KB cluster file system consumes 4 KB of disk space (3,996 bytes wasted).
- A 4,097-byte file consumes 8 KB (one full cluster plus a second cluster used for just one byte).
- A 10 MB file in a 4 KB cluster file system consumes 2,560 clusters, all but the last one entirely full.
- The unused portion of the last cluster (file size mod cluster size) is called “slack space” and can contain remnants of previously-stored data.
Different terminology, same concept
The Systoolsgroup terminology guide captures the distinction across platforms: “Clusters are the logical group of sectors used to store files on Windows file systems… The Block Size denotes the physical data unit that the operating system reads and writes data into, and this unit is often found on Linux and Unix file systems such as ext4 and XFS.” The same fundamental concept appears under different names:
- Cluster: NTFS, FAT, exFAT, ReFS (Microsoft file systems)
- Allocation Unit: Microsoft’s formatting term, used in the Windows format dialog
- Block: ext2/3/4, XFS, JFS (Linux file systems)
- Allocation Block: HFS+, APFS (Apple file systems)
- Page: some specialized file systems and databases
The differences are largely terminological; the underlying concept is the same across all modern file systems.
Cluster sizes available
The ScienceDirect allocation size overview describes the typical NTFS options: “All disk partitions larger than 2 GB have a default cluster size of 4 KB. You can overwrite this setting and use one of the large cluster sizes: 8 KB, 16 KB, 32 KB, and 64 KB.”2 Most modern file systems support cluster sizes ranging from 512 bytes (rarely used today) up to 2 MB (very specialized). The vast majority of installations use 4 KB clusters because the default is appropriate for the vast majority of workloads.
Sectors vs Clusters: The Hardware-Software Boundary
The relationship between sectors and clusters is one of the clearest hardware-software boundaries in storage architecture. Sectors are physical hardware units; clusters are file system constructs that group sectors together.3
Sectors: the hardware unit
A sector is the basic unit of storage on the physical disk:
- Traditional disks: 512-byte sectors (the historical standard since the early days of hard drives).
- Advanced Format (AF) disks: 4096-byte (4 KB) physical sectors with optional 512-byte logical emulation for compatibility.
- SSDs: typically present 512-byte logical sectors but have 4 KB or 8 KB internal NAND pages.
- Enterprise SAS drives: sometimes use 520 or 528-byte sectors with extra bytes for end-to-end checksums.
Sector size is determined by the drive’s hardware and firmware; it’s not negotiable from the operating system’s perspective for traditional drives, though some enterprise drives can be reformatted at low level to change sector size.
Clusters: the file system unit
A cluster is a contiguous group of sectors that the file system treats as a single allocation unit. The relationship is straightforward:
- A 4 KB cluster on a traditional 512-byte sector disk consists of 8 sectors.
- A 4 KB cluster on a 4 KB sector AF disk consists of exactly 1 sector.
- A 64 KB cluster on a traditional 512-byte sector disk consists of 128 sectors.
- A 64 KB cluster on a 4 KB sector AF disk consists of 16 sectors.
Cluster size is determined at format time; the file system records its cluster size in volume metadata (the boot sector for NTFS, the superblock for ext, etc.).
The Advanced Format alignment requirement
AF drives with 4 KB physical sectors require cluster boundaries to be aligned to 4 KB. If a cluster straddles two physical sectors, every read or write to that cluster causes the disk to read or write both physical sectors, doubling IO. Misaligned partitions on AF drives can produce 2x performance degradation; modern partitioning tools default to 1 MB-aligned partition starts to avoid this. Older systems sometimes started partitions at sector 63 (the historical default), which produces misaligned clusters on AF drives.
Why the abstraction matters
The sector-cluster boundary is what makes file systems portable across different disk hardware. The same NTFS volume can be moved between a traditional 512-byte sector disk and a 4 KB sector AF disk without any file system changes; the file system continues to use 4 KB clusters, with the underlying sector mapping handled transparently. This abstraction is what lets file systems evolve independently of hardware; new sector sizes can be introduced without breaking existing file systems, and new file systems can be designed without committing to specific hardware sector sizes.
Sector failures and cluster impact
When physical sectors fail, the impact at the cluster level depends on the sector-to-cluster ratio:
- One bad sector in a 4 KB cluster on a 512-byte sector disk: the entire 4 KB cluster is unreadable (8 sectors, one bad), affecting whatever file owns that cluster.
- One bad sector in a 4 KB cluster on a 4 KB sector AF disk: the entire cluster is unreadable (only 1 sector, that one bad).
- One bad sector in a 64 KB cluster on a 512-byte sector disk: the entire 64 KB cluster is unreadable (128 sectors, one bad), affecting more file content.
Larger clusters concentrate damage; smaller clusters spread it out. From a recovery perspective, smaller clusters mean less data lost per bad sector; this is one minor argument in favor of smaller cluster sizes for drives with high bad-sector probabilities.
Cluster Size and the Performance Tradeoffs
Cluster size affects multiple performance and space-efficiency dimensions. Understanding the tradeoffs helps with both file system selection and recovery work.4
Wasted space (internal fragmentation)
The HowToGeek waste calculation provides specific numbers: “If you have an allocation unit size of 64 kilobytes and you write a 3-kilobyte file to it, that entire block will be filled. That means you’ve used up 64 kilobytes of storage to store only 3 kilobytes. If you had enough 3 KB files to fill an entire drive formatted that way, you’d wind up wasting more than 95% of the drive’s total volume. If you shrink your allocation unit size to 4KB, you’d only waste 25% of the drive’s total volume.”
The general formula: average wasted space per file = half the cluster size. Practical implications:
- 4 KB clusters with 100,000 files: ~200 MB wasted (4KB / 2 × 100,000)
- 64 KB clusters with 100,000 files: ~3.2 GB wasted (64KB / 2 × 100,000)
- 4 KB clusters with 1 million files: ~2 GB wasted
- 64 KB clusters with 1 million files: ~32 GB wasted
IO amplification (the Microsoft framing)
The Microsoft TechCommunity ReFS documentation describes the performance penalty of mismatched cluster and IO sizes: “IO amplification refers to the broad set of circumstances where one IO operation triggers other, unintentional IO operations. Consider the following scenarios where a ReFS volume is formatted with 64K clusters: If a 4K write is made to a range currently in the capacity tier, ReFS must read the entire cluster from the capacity tier into the performance tier before making the write. By choosing 4K clusters instead of 64K clusters, one can reduce the number of IOs that occur that are smaller than the cluster size, preventing costly IO amplifications.”
Metadata overhead
Smaller clusters mean more metadata. The ScienceDirect overview describes the FAT32 example: “Going back to the FAT32 example above for a 256-GB drive, a 1-KB cluster size requires 1 GB of file allocation table space, but wastes only 10 MB of storage space with 20,000 user files, while a 64-KB cluster size requires only 16 MB of table space, but wastes 640 MB of storage space for the same number of files.” The FAT32 case is extreme because FAT scales linearly with cluster count; NTFS and ext4 use more efficient metadata structures that don’t scale as badly, but the principle still applies: smaller clusters require more allocation map space.
Sequential read performance
Larger clusters improve sequential read performance for large files because the file system can issue larger IO requests with fewer metadata lookups. The ScienceDirect documentation captures the Exchange example: “In the ‘Partition Design’ section on TechNet, Microsoft recommends using an NTFS allocation size unit of 64 KB for the file system with the Exchange databases. This provides performance benefits for the large sequential read operations of Exchange backups.” For workloads dominated by sequential access to large files (databases, video editing, media servers), larger clusters can substantially improve throughput.
Cluster size selection summary
| Cluster size | Best for | Avoid for |
|---|---|---|
| 4 KB | General desktop/laptop use, mixed workloads, small files | (rarely a bad choice) |
| 8-16 KB | File servers with mostly medium files | Drives with many tiny files |
| 32 KB | Specialized large-file workloads | General desktop use |
| 64 KB | Database servers, video editing, Exchange databases, large sequential reads | Mixed workloads, drives with many small files |
| 1-2 MB | Specialized media archives | Almost everything else |
When to deviate from defaults
The HowToGeek guidance is consistent with broader best practice: “You should stick with the default allocation unit size that is suggested when you format your storage device unless you have an extremely specific reason to change it. For the average NTFS drive, that will be 4,096 bytes, or 4 KB.” Specific scenarios where larger clusters genuinely help include database servers, dedicated video editing workstations, and drives storing only large media files. For everything else, 4 KB is the right default.
Cluster Allocation Across File Systems
Different file systems implement the cluster concept with different details. Understanding the differences helps with cross-platform recovery and migration work.
NTFS clusters
NTFS uses 4 KB clusters by default for partitions over 2 GB. The cluster size is recorded in the Volume Boot Record at offset 0x0D as “sectors per cluster” combined with the bytes-per-sector field at offset 0x0B. The MFT tracks file allocations using cluster runs (start cluster + length pairs); the $Bitmap system file (file 6 in the MFT) tracks which clusters are allocated vs free. NTFS supports cluster sizes from 512 bytes up to 2 MB, with 4 KB the universal default.
ext family blocks
The ext2/3/4 file systems use blocks instead of clusters; the concept is identical. Default block size is 4 KB on modern installations, sometimes 1 KB or 2 KB on older or smaller volumes. The block size is recorded in the file system superblock; inodes reference data via either traditional block pointer arrays (ext2/3) or extent trees (ext4) that describe ranges of contiguous blocks. The ext family also has a “fragments” concept allowing sub-block allocation for small files, though it’s rarely used in practice.
FAT family clusters
FAT uses clusters identically to NTFS, but with a critical limitation: each FAT entry is a fixed-width pointer (12, 16, or 32 bits depending on FAT variant), and the maximum number of clusters is bounded by the entry width. FAT16 supports 65,536 clusters maximum; with 32 KB clusters that’s a 2 GB volume limit, which is why FAT16 was painful for larger drives. FAT32 supports 268 million clusters with 32-bit entries; cluster sizes in FAT32 must be larger on bigger volumes to stay within the 268M limit.
exFAT
exFAT was designed to address FAT32’s limitations. It supports much larger volumes (up to 128 PB) and cluster sizes up to 32 MB. Default cluster sizes scale with volume size: 4 KB for < 256 MB, 32 KB for typical use, up to 32 MB for very large media volumes. exFAT is the default for SDXC cards and is widely used for cross-platform external drives because both Windows and macOS support it natively.
APFS allocation blocks
APFS uses 4 KB allocation blocks by default and supports variable allocation block sizes. The copy-on-write design means allocation blocks are written to new locations rather than overwritten in place, with metadata trees pointing to the current allocations. APFS’s container/volume distinction lets multiple volumes share a single allocation pool, with allocation blocks managed at the container level.
ReFS clusters
The Microsoft TechCommunity ReFS documentation captures the design: “ReFS offers both 4K and 64K clusters. 4K is the default cluster size for ReFS, and we recommend using 4K cluster sizes for most ReFS deployments because it helps reduce costly IO amplification.” ReFS’s resilience features (block cloning, integrity streams) interact with cluster size in nuanced ways; the recommendation is 4 KB for most workloads, with 64 KB only for specific large-file deployments.
Clusters and Data Recovery
Clusters are the basic unit of data recovery. Every recovered file ultimately means knowing which clusters belonged to which file and reading those clusters back successfully. The cluster concept ripples through every aspect of recovery work.
Metadata-based recovery
When file system metadata is intact, recovery is straightforward: read the metadata to identify the file’s clusters, then read those clusters. NTFS recovery reads MFT records to find cluster runs in the $DATA attribute; ext4 recovery reads inode extent trees. The recovery tool’s job is to translate logical file requests into the cluster-level reads needed to assemble the file’s content. When metadata is intact, this is mechanical and reliable.
Cluster runs and extents
Modern file systems store cluster allocations efficiently using cluster runs (NTFS) or extents (ext4, XFS). A run/extent describes a contiguous range of clusters with two numbers: starting cluster and length. A 1 MB file allocated in one contiguous run takes one extent descriptor; the same file fragmented across 256 separate clusters would take 256 extent descriptors. Recovery tools must parse run/extent metadata correctly to find all the clusters belonging to a fragmented file; tools that only handle simple cases miss data in heavily-fragmented files.
File carving as cluster-aware fallback
When metadata is destroyed, file carving falls back to scanning the entire disk looking for cluster-sized chunks that contain identifiable file content. The Sleuth Kit, foremost, scalpel, and photorec all implement variations of this approach. Carving recovers content but loses original filenames, timestamps, and directory structure; the cluster size determines the granularity of the reconstruction. For files that don’t fit in contiguous clusters, carving can produce corrupted output if it can’t identify cluster ordering correctly; this is one reason carving is a last resort rather than first choice.
Slack space forensics
The unused portion of partially-filled clusters (slack space) is a rich source of forensic evidence. When a file uses N bytes of a cluster’s M bytes, the remaining M-N bytes still contain whatever was there before. Common slack space artifacts include partial contents of previously-deleted files, fragments of memory that was paged to disk, and traces of operating system activities. Forensic tools specifically extract slack space; consumer recovery software typically ignores it because it doesn’t represent recoverable files in the conventional sense.
Bad clusters
When physical sectors fail, the affected clusters become unreadable. The file system tracks bad clusters in a dedicated structure ($BadClus on NTFS, badblocks list on ext); files containing bad clusters are typically inaccessible until the bad clusters are remapped or the data is recovered through alternative means. Recovery from bad-cluster damage typically requires sector-level access using tools like ddrescue or HDDSuperClone that can read around bad sectors and reconstruct the cluster from whatever is recoverable. Cleanroom recovery can sometimes access sectors that fail through normal interfaces.
The cluster size and recovery interaction
Larger clusters have several recovery implications:
- More damage per bad sector: a single bad sector destroys the entire cluster; larger clusters mean more data lost per failure.
- More slack space per file: larger clusters mean more bytes of historical content potentially preserved in slack.
- Easier carving: larger clusters mean fewer cluster boundaries within a file, simplifying signature-based reconstruction.
- More fragmented metadata recovery: larger clusters with the same data produces fewer cluster references in metadata, simplifying parsing.
The cluster is the most fundamental allocation concept in file system design and the most fundamental unit of data recovery. Every recovered file ultimately reduces to the question of “which clusters belong to this file, and can they all be read successfully?”; understanding clusters is what makes file system recovery work tractable. The 4 KB default has been stable for two decades because it represents a genuine sweet spot for typical workloads; the cases where larger clusters help (databases, video, large sequential reads) are specialized enough to justify deviation only when explicitly warranted.5
For users wondering about cluster size selection during formatting, the practical guidance is consistent across sources: stick with the default unless you have a specific reason to deviate. The HowToGeek summary captures it well: 4 KB works for almost everyone, and the alternatives are rarely worth the tradeoffs in waste or performance for typical desktop and laptop workloads. Specialized workloads (Exchange databases on dedicated drives, video editing workstations, media archives) can benefit from larger clusters but should be deliberately chosen rather than reflexively applied. The cost of choosing wrong is mostly wasted space (with too-large clusters) or modest performance loss (with mismatched cluster and IO sizes); neither is catastrophic, but neither is desirable when the default works fine.
For users facing potential data loss, the cluster-related guidance reinforces standard recovery best practice: stop using the file system immediately to preserve cluster-level state. Continued operation can overwrite clusters that contained deleted file data; recovery software can extract data from intact clusters but can’t reconstruct overwritten ones. For severely damaged file systems, professional services using specialized tools (ddrescue for sector-level imaging, PC-3000 for firmware-level access) can recover clusters that consumer software can’t reach. The combination of metadata-based recovery (when file system structures are intact), file carving (when metadata is gone but clusters survive), and physical-level recovery (when sectors themselves have failed) covers the full spectrum of cluster-related recovery scenarios. Comprehensive backups remain the primary protection because recovery from cluster-level damage is uncertain and time-consuming compared to simply restoring from backup.
Cluster FAQ
A cluster (also called an allocation unit on Windows or a block on Unix-like systems) is a contiguous group of disk sectors that a file system treats as a single allocation unit. The cluster is the smallest unit of disk space the file system can allocate to a file; even a 1-byte file consumes one full cluster’s worth of disk space. Clusters exist to reduce the metadata overhead of tracking which sectors hold which files: tracking 250 million 4 KB clusters for a 1 TB drive is much more practical than tracking 2 billion 512-byte sectors. Standard cluster sizes are 4 KB, 8 KB, 16 KB, 32 KB, and 64 KB.
Sectors are physical hardware units defined by the storage device: traditional disks use 512-byte sectors, and modern Advanced Format drives use 4096-byte sectors. The disk’s firmware reads and writes data in sector units. Clusters are file system constructs that group multiple sectors into a single allocation unit. A 4 KB cluster on a traditional 512-byte sector disk consists of 8 sectors; on an Advanced Format 4 KB sector disk, a 4 KB cluster is exactly one sector. The cluster size is chosen by the file system at format time and affects performance and space efficiency; the sector size is fixed by the hardware and cannot be changed without reformatting at a low level. Files are allocated cluster by cluster but read and written sector by sector at the hardware level.
For modern file systems, 4 KB is the default cluster size. Microsoft Knowledge Base Article 140365 documents that all NTFS partitions larger than 2 GB default to 4 KB clusters; ext4 defaults to 4 KB blocks; APFS uses 4 KB allocation blocks; exFAT typically defaults to 4 KB. The 4 KB default matches typical CPU memory page sizes and the physical sector size of Advanced Format hard drives, which makes it efficient for both performance and storage. Larger cluster sizes (8 KB, 16 KB, 32 KB, 64 KB) are typically chosen only for specific workloads that benefit from them: NTFS for Exchange databases is often formatted with 64 KB clusters for sequential read performance; large-file media archives sometimes use 16 KB or 32 KB clusters; ReFS supports 4 KB and 64 KB clusters with 4 KB recommended for most deployments.
Cluster size determines how much space is wasted when small files are stored. Each file consumes at least one full cluster regardless of its actual size; a 1-byte file in a 4 KB cluster wastes 4,095 bytes, and a 1-byte file in a 64 KB cluster wastes 65,535 bytes. The HowToGeek allocation unit guide describes the calculation: with 4 KB clusters, 100,000 files waste an average of 200 MB; with 64 KB clusters, the same 100,000 files waste 3.2 GB. The waste calculation assumes random file sizes; actual waste depends on file size distribution. The general rule is that average wasted space per file is half the cluster size, so file systems with many small files (typical desktop workloads) benefit from smaller clusters, while file systems with few large files (media servers, video editing) benefit from larger clusters.
IO amplification refers to situations where a single user-level IO operation triggers multiple unintended IO operations at the file system or storage level. The Microsoft TechCommunity ReFS documentation describes the cluster-related cause: when the cluster size exceeds the size of the IO, certain workflows trigger unintended IOs. For example, on a volume with 64 KB clusters, a 4 KB write requires the file system to read the entire 64 KB cluster, modify the 4 KB region, and write back the full 64 KB cluster. This read-modify-write amplifies a single 4 KB user write into 64 KB of read traffic and 64 KB of write traffic. IO amplification can dramatically reduce effective performance, especially for write-intensive workloads. Choosing 4 KB clusters instead of 64 KB clusters typically reduces IO amplification because most operating system writes are 4 KB, matching the cluster size and avoiding the read-modify-write penalty.
Clusters are the basic unit of data recovery: every recovered file ultimately means knowing which clusters belonged to which file and reading those clusters back. The MFT in NTFS stores cluster runs (start cluster + length pairs) describing where each file’s data lives; ext4 inodes use extent trees that describe cluster ranges in similar fashion. When file system metadata is intact, recovery is straightforward: read the metadata to identify the file’s clusters, then read those clusters. When metadata is damaged, recovery becomes more complex: tools must scan the disk looking for clusters that contain identifiable file content (file carving) and reconstruct files from cluster contents alone. Slack space (the unused portion of partially-filled clusters) often contains remnants of previously-deleted files, providing forensic evidence beyond the file system’s current state. Bad clusters where physical sectors have failed make the affected files unreadable through normal means and require sector-level recovery techniques.
Related glossary entries
- Sector: the physical hardware unit that clusters group together.
- $MFT: NTFS’s central data structure; stores cluster runs in $DATA attributes.
- Inode: Unix per-file metadata; stores block (cluster) pointers or extent trees.
- Slack Space: unused portion of partially-filled clusters; rich forensic resource.
- File Carving: cluster-level recovery technique when metadata is destroyed.
- Bad Sectors: failed sectors that destroy entire clusters.
- NTFS: Windows file system that uses 4 KB clusters by default.
Sources
- Microsoft TechCommunity: Cluster size recommendations for ReFS and NTFS (accessed May 2026)
- ScienceDirect: Allocation Size: an overview
- Systoolsgroup: Allocation Unit Size vs Cluster Size vs Block Size
- HowToGeek: What Should I Set the Allocation Unit Size to When Formatting?
- Microsoft Knowledge Base 140365 (referenced via ScienceDirect)
About the Authors
Data Recovery Fix earns revenue through affiliate links on some product recommendations. This does not influence our reference content. Glossary entries are written and reviewed independently based on documented research, vendor documentation, independent testing, and recovery-engineer review. If anything on this page looks inaccurate, outdated, or worth revisiting, please reach out at contact@datarecoveryfix.com and we’ll review it promptly.
