The File That Takes Up More Room Than It Is
Copy 100,000 small text files onto a drive. Each one is 200 bytes. That's 20 MB of data.
Check the drive's used space and it reports something closer to 400 MB.
Nothing is corrupted, nothing is duplicated, and the files are exactly the size they claim to be. The difference is allocation overhead — the gap between how much data a file contains and how much space the filesystem reserves for it.
Cluster Size and Slack Space
Filesystems don't allocate space byte by byte. They allocate in fixed-size blocks, called clusters or allocation units.
Typical cluster sizes:
- NTFS: 4 KB by default for most volume sizes
- ext4: 4 KB default
- APFS: 4 KB
- exFAT: varies widely with volume size, often 128 KB on large drives
A 200-byte file on a 4 KB cluster consumes an entire 4 KB cluster. The remaining 3,896 bytes are unusable by anything else. That wasted portion is slack space.
For our 100,000 files:
Actual data: 100,000 × 200 B = 20 MB
Space consumed: 100,000 × 4 KB = 400 MB
Wasted: 380 MB
That's 95% overhead. The files occupy twenty times the space they contain.
The effect scales inversely with file size. A 3.9 MB file on 4 KB clusters wastes at most 4 KB — negligible. It's small files where this dominates, and that's exactly what you have in a source code repository, a maildir, or a cache directory.
Average waste per file is roughly half the cluster size, assuming file sizes are randomly distributed relative to cluster boundaries. So a directory of a million small files on a 4 KB filesystem wastes around 2 GB.
Why exFAT is worse
exFAT is common on large USB drives and SD cards, and it defaults to much larger cluster sizes on big volumes — 128 KB is typical on a 1 TB drive.
Put 100,000 200-byte files on that and you consume 12.8 GB to store 20 MB. It's the same mechanism, amplified by a factor of 32.
Filesystem Metadata
Beyond slack space, the filesystem itself occupies room before you store anything.
Inodes and MFT entries. Every file needs a metadata record — permissions, timestamps, ownership, and pointers to its data blocks. On ext4 these are inodes, allocated at format time in a fixed quantity. On NTFS they're records in the Master File Table.
ext4 typically reserves an inode for roughly every 16 KB of volume space by default. On a 1 TB volume that's tens of millions of inodes consuming several gigabytes of space, whether or not you use them. It also means you can run out of inodes while having free space — a confusing failure mode where the disk reports space available but file creation fails.
Journals. Journaling filesystems maintain a log of pending metadata changes for crash consistency. ext4's default journal is typically in the low hundreds of megabytes.
Reserved blocks. ext4 reserves a percentage of the volume — 5% by default — for the root user. This prevents a full disk from making the system unrecoverable, since root still has room to operate. On a 4 TB volume that's 200 GB set aside. It can be reduced with tune2fs on data volumes where the safety margin isn't needed.
Superblock backups, block group descriptors, allocation bitmaps. Individually small, collectively another percentage point or two.
Small Files Made Cheaper
Several filesystems have specific optimisations for the small-file case.
Inline data / resident files. NTFS stores very small files entirely within their MFT record — no separate cluster allocation at all. ext4 has a similar inline_data feature. The threshold is on the order of a few hundred bytes to a couple of kilobytes depending on record size and how much of it is consumed by other attributes.
Tail packing. Some filesystems pack the final partial block of multiple files into a shared block, reclaiming much of the slack space. Btrfs does this for small files.
Block suballocation. Similar idea, allowing a single block to hold fragments of several files.
None of these are universal, and whether they're active depends on the filesystem, its version, and how it was formatted.
Converting Between the Numbers
When you're reconciling reported sizes, the binary-versus-decimal distinction compounds with allocation overhead. The Data Storage Converter handles the unit conversion:
- Enter the value you have.
- Select the source unit — bytes, KB, KiB, MB, MiB, GB, GiB, TB, TiB.
- Read the equivalents.
The distinction matters here because different tools report differently. On Linux, du reports allocated space while ls -l reports apparent file size — running both on the same directory shows you the overhead directly:
du -sh /path → space consumed on disk
du -sh --apparent-size /path → sum of file sizes
The gap between those two numbers is your allocation overhead.
On Windows, the file properties dialog shows "Size" and "Size on disk" for exactly this reason.
Where This Shows Up in Practice
A source repository. A large project with tens of thousands of small source files, plus a .git directory containing many more small objects, can consume several times its nominal size.
Node modules. A node_modules directory with hundreds of thousands of small files is a textbook case. Reported project size and disk consumption diverge dramatically.
Mail storage in maildir format. One file per message, many of them small. A mail server storing millions of messages pays substantial slack overhead.
Thumbnail and cache directories. Thousands of small images, each far below cluster size.
Docker layers and container images. Many small files across many layers, with overlay filesystem metadata on top.
Backup sizing. Estimating backup storage from the sum of file sizes underestimates the target requirement if the destination filesystem has a large cluster size. Estimating from allocated size overestimates if the backup format packs files together, as tar and most backup tools do.
Choosing a Cluster Size
If you're formatting a volume for a known workload, cluster size is a genuine tradeoff.
Smaller clusters (1–4 KB):
- Less slack space, better for many small files
- More metadata to track, marginally more fragmentation
- More allocation-table entries
Larger clusters (16–64 KB):
- Wasteful for small files
- Fewer allocations per large file, which historically helped sequential throughput on spinning disks
- Smaller allocation tables
For a general-purpose system, the 4 KB default is a sensible compromise and matches the memory page size on most architectures, which helps with memory-mapped I/O.
For a volume storing only large media files, a bigger cluster costs almost nothing in slack and reduces metadata overhead. For a volume holding millions of small files, keep it small — and consider whether the workload would be better served by packing the data into archives or a database rather than the filesystem.
Practical Tips
Compare du and du --apparent-size before sizing storage. The gap tells you your real overhead for that workload.
Archive directories of small files you don't actively use. A tar archive packs files contiguously, eliminating slack. Compressing it saves more.
Check inode usage on ext4, not just block usage. df -i shows it. Running out of inodes on a disk with free space is a genuinely confusing outage.
Reduce reserved blocks on large data volumes. 5% of a multi-terabyte volume is a lot of space set aside for a safety margin that only matters on system volumes.
Don't format large drives as exFAT if you'll store many small files. The default cluster size makes the overhead severe.
Account for both binary units and overhead when planning capacity. A "4 TB" drive gives you roughly 3.64 TiB, minus filesystem structures, minus whatever slack your workload generates.
FAQ
Why does my folder show two different sizes? One is the sum of file sizes; the other is space actually allocated on disk. The difference is slack space from partially-used clusters.
Can I reduce slack space without reformatting? Not directly — cluster size is set at format time. You can reduce its impact by archiving small files or moving them to a filesystem with a smaller cluster size.
What is the ideal cluster size? 4 KB for general use. Larger for volumes holding only big files; smaller isn't usually worth the metadata cost.
Why can I run out of inodes with free disk space? ext4 allocates a fixed number of inodes at format time. Storing more files than that number fails regardless of available blocks.
Do SSDs change any of this? Filesystem allocation behaves the same way. SSDs add their own layer of internal block management and over-provisioning, which is separate from filesystem overhead.
Does compression eliminate slack space? Filesystem-level compression can reduce it, and packing files into a single compressed archive eliminates it entirely for the archived set.
The Takeaway
Storage capacity isn't consumed by data alone — it's consumed by data rounded up to the nearest allocation unit, plus the structures the filesystem needs to track it all. For workloads dominated by small files, that rounding can multiply your real consumption several times over, and knowing it in advance is the difference between a capacity plan that holds and one that doesn't.
Convert between bytes, KB, MB, GB, TB and their binary equivalents free with the Data Storage Converter at sadiqbd.com — no sign-up, instant results.
