Filesystem Overhead Calculator
Estimate metadata and journaling overhead a filesystem subtracts from raw partition capacity.
Inputs
Estimated Usable Capacity (GB)
967.50
Overhead (GB)
32.50
Overhead Percentage
3.25%
Usable Capacity Range
950 - 985 GB
Step by step
Values used
Total Raw Capacity (GB) = 1,000; Filesystem Type = ext4 (1.5% - 5%); Custom Overhead (%) = 3
Usable capacity
usable_capacity = total_capacity × (1 − overhead%)
Estimated Usable Capacity (GB)
= 967.50
Overhead (GB)
= 32.50
Overhead Percentage
= 3.25
Usable Capacity Range
= 950 - 985 GB
How it works
Formatting a raw block device with a filesystem always sacrifices some capacity to superblocks, inode tables, journals, checksums and reserved blocks. ext4 reserves 5% for root by default plus inode table overhead (roughly 1.5-5% total depending on inode ratio); XFS is leaner (0.5-1%) since it allocates metadata dynamically; Btrfs and ZFS trade more overhead (3-9%) for checksumming, copy-on-write metadata and reserved 'slop space' that keeps copy-on-write operations from deadlocking when nearly full.
Formula
Usable capacity
usable_capacity = total_capacity × (1 − overhead%)
- C
- total raw capacity
- o
- overhead fraction for the filesystem type
Guides that use this calculator
Frequently Asked Questions
Why does df show less space than the disk's rated capacity?
Part of the gap is decimal-vs-binary unit labeling (a '1TB' drive is ~931 GiB), and part is genuine filesystem overhead: metadata structures, journal space, and — for ext4 — a default 5% root-reserved block pool that prevents the root user from being locked out when the disk fills.
Can I reduce ext4's reserved block percentage?
Yes, with tune2fs -m <percent> /dev/xxx. Lowering it from the 5% default reclaims usable space but removes the safety margin that lets root-owned daemons keep writing (e.g. logging) when regular users see a full disk.
Why does Btrfs have higher overhead than XFS?
Btrfs stores checksums for data and metadata, keeps multiple metadata copies (dup profile by default on single devices), and uses copy-on-write which temporarily needs extra free space for atomic updates — all of which XFS's simpler B+tree metadata layout avoids.