INTERNAL FRAGMENTATION space wasted INSIDE an allocated block. A file's last block is almost never exactly full. average waste = block_size / 2 per file MEASURED on this machine (APFS, 4096-byte blocks): file size blocks allocated waste ────────────────────────────────────── 1 byte 4096 bytes 4095 bytes (99.98%!) 100 bytes 4096 bytes 3996 bytes 4096 bytes 4096 bytes 0 bytes (perfect fit) 4097 bytes 8192 bytes 4095 bytes (one byte over) 10000 bytes 12288 bytes 2288 bytes READ THE 4097-BYTE ROW. One byte past a block boundary costs a whole extra block — 4095 wasted bytes. That is the sharpest illustration of why block size matters. EXTERNAL FRAGMENTATION free space exists but is scattered in pieces too small to hold a new file contiguously. · afflicts CONTIGUOUS allocation badly · does NOT afflict linked or indexed allocation, because any free block will do · but it still degrades PERFORMANCE for indexed allocation: a file whose blocks are scattered reads slowly, which is what "the disk is fragmented" popularly means NOTE THE DISTINCTION: with indexed allocation, external fragmentation costs SPEED, not CAPACITY. With contiguous allocation it costs capacity — the write fails outright.

THE TRADE-OFF, stated precisely: LARGE BLOCKS ✔ fewer blocks per file → smaller metadata, fewer pointers, faster sequential reads ✗ MORE internal fragmentation SMALL BLOCKS ✔ LESS internal fragmentation ✗ more pointers per file, larger inodes and bitmaps, more seeks WORKED CALCULATION — 1,000,000 files averaging 2 KB each, which is a realistic build cache or mail spool: block allocated per file total on disk amplification ────────────────────────────────────────────────────────── 512 B 2048 B (4 blk) 1.91 GiB 1× 1024 B 2048 B (2 blk) 1.91 GiB 1× 4096 B 4096 B (1 blk) 3.81 GiB 2× 16384 B 16384 B (1 blk) 15.26 GiB 8× 65536 B 65536 B (1 blk) 61.04 GiB 32× At 64 KB blocks, 1.91 GiB of real data occupies 61 GiB of disk — a 32× amplification. At 512 B or 1 KB it is exact, because 2048 divides evenly by both. THE SAME FILES AT 1 MB EACH instead of 2 KB: 512 B blocks → 2048 blocks per file → 2,048,000,000 pointers to track. The metadata becomes the problem. 64 KB blocks → 16 blocks per file → trivial metadata, negligible waste (avg 32 KB per 1 MB file = 3%) CONCLUSION: the right block size depends on the file-size DISTRIBUTION, not on the disk. That is why filesystems expose it as a format-time option and why databases let you choose a page size. MEASURED CONTEXT — this machine uses 4096-byte filesystem blocks but 16384-byte MEMORY pages. Two different granularities, chosen for two different distributions: file sizes versus working-set locality. BLOCK SUB-ALLOCATION — how modern filesystems escape the trade: · FRAGMENTS / BLOCK SUFFIXES (UFS): allow the last partial block of a file to be shared with other files' tails · TAIL PACKING (ReiserFS, btrfs): pack several small files' tails into one block · INLINE DATA (ext4, APFS): store a very small file INSIDE its own inode, using the space the block pointers would occupy. A 60-byte file then costs ZERO data blocks. Inline data is why a filesystem full of tiny files can now be far more efficient than the 4095-bytes-wasted measurement above suggests — the measurement shows what happens when the file is big enough to need a block at all.

FOR EXTERNAL FRAGMENTATION (contiguous allocation): COMPACTION / DEFRAGMENTATION — relocate files so free space coalesces into large runs. ✔ restores contiguity and sequential read speed ✗ expensive: it rewrites large amounts of data ✗ on an SSD it is actively HARMFUL — it causes wear with no benefit, because an SSD has no seek penalty. Never defragment an SSD. EXTENT-BASED ALLOCATION — the modern answer. Instead of tracking individual blocks, record (start, length) EXTENTS. ext4, XFS, NTFS, APFS all use extents ✔ a 1 GB contiguous file needs ONE extent record instead of 262,144 block pointers ✔ encourages contiguity, since the allocator naturally seeks large runs ✔ far smaller metadata DELAYED ALLOCATION (allocate-on-flush) — do not choose blocks when write() is called; wait until the data is actually flushed, by which time the total size is known and one large contiguous extent can be picked. ✔ dramatically reduces fragmentation for files written incrementally ✗ a crash before the flush loses more data, which caused the well-known ext4 "zero-length file after crash" complaints PREALLOCATION — the application declares the final size up front: fallocate() / posix_fallocate() Databases and torrent clients do this precisely to get one contiguous extent. FOR INTERNAL FRAGMENTATION: · smaller blocks (with the metadata cost) · tail packing / fragments · inline data in the inode for tiny files · at the application level: PACK many small items into one large file, which is what git packfiles, JAR/ZIP archives and database tablespaces all do THE UNIFYING OBSERVATION: file-system fragmentation and memory fragmentation are the same problem with the same solutions. contiguous allocation ↔ contiguous memory allocation indexed allocation ↔ paging extents ↔ huge pages compaction ↔ memory compaction Fixed-size units eliminate external fragmentation and create internal fragmentation; variable-size units do the reverse. There is no third option.