Why cp Can Finish Instantly: Understanding Inodes, Block Indexing and Sparse Files

A colleague observed that copying a 100 GB file with cp completed in less than a second, which seemed impossible on a SATA HDD.

Measurements show the file size reported by ls -lh is 100 GB, but du -sh ./test.txt reports only 2 MB, indicating a sparse file.

The stat ./test.txt output confirms the logical size (Size: 107374182400 bytes) while only a few blocks (Blocks: 4096) are allocated.

File‑system basics: data is stored in fixed‑size blocks (typically 4 KB). An inode holds metadata and an array of block pointers. The first 12 entries are direct pointers; the 13th, 14th, and 15th entries are single, double, and triple indirect pointers, enabling addressing up to roughly 4 TB.

In a sparse file the logical size recorded in the inode can far exceed the physical blocks allocated; unwritten regions consume no disk space, so copying such a file only copies the allocated blocks, making cp appear extremely fast.

Typical write flow: write data → allocate blocks → store block numbers in the inode (direct or indirect). Read flow: read inode → follow pointers to retrieve blocks.

Performance impact: small files using only direct pointers need two disk reads (inode + data block). Large files that require indirect indexing may need up to five reads (inode + up to three indirect blocks + data block).

Conclusion: the observed speed is due to the file being sparse; the file’s size attribute reflects logical length, while actual disk usage is determined by allocated blocks.