where the max file size comes from
More OS this week: file management and inodes. The exam question is always some version of "what's the largest file this filesystem can hold?", and it looked like memorising until I drew the pointers.
what an inode points at
An inode doesn't hold the file's data. It holds the file's metadata and a short list of block pointers. Some point straight at data, and some point at blocks full of more pointers.
one formula
Take a typical setup (these are the assumptions; change them and the answer changes):
- block size 4 KB (4,096 bytes)
- pointer size 4 bytes
- 12 direct pointers, plus one each of single, double and triple indirect
- sizes are powers of two: KB = 1,024 bytes, so "4 TB" here is 4 TiB
One block holds 4,096 / 4 = 1,024 pointers. Call that n. Then:
max blocks = 12 + n + n² + n³
max size = max blocks × block size| pointer | blocks it reaches | data |
|---|---|---|
| 12 direct | 12 | 48 KB |
| single indirect | 1,024 | 4 MB |
| double indirect | 1,048,576 | 4 GB |
| triple indirect | 1,073,741,824 | 4 TB |
| total | 1,074,791,436 | about 4 TB |
Almost all of it comes from the triple-indirect pointer. The direct pointers barely register, but they're why small files are fast: no extra block reads to find the data.
things I want to remember
n = block size / pointer size. It's the only number you derive.- Each indirect level multiplies by
nonce more. - Real filesystems often cap the size elsewhere too, so this formula gives the limit of the pointer scheme, not always the real one. Classic ext2 with 4 KB blocks is the example: the pointers reach about 4 TB, but the inode's
i_blocksfield counts 512-byte units in 32 bits, which caps a file at about 2 TB (kernel mailing list). - Byte 5 GB of a file is past what the direct, single and double pointers reach (about 4 GB), so it lives under the triple-indirect pointer. Reading it cold costs three pointer-block reads before the data block. Big files pay for their size on random access, unless those blocks are cached.