Why a 10 MiB File Can Have 4 MiB of Allocated Blocks

A hole has readable offsets inside the file's length

A hole inside a file's logical length reads as zeros; the filesystem need not store those zeros as ordinary data blocks. Reads can continue beyond it.

Linux man-pages 6.19 states that seeking beyond the end does not enlarge a file. If data is later written there, the intervening gap reads as zeros.

References: [S1]

Read byte length and allocated blocks in their own units

For a regular file, Linux's inode documentation identifies st_size as its length in bytes. It identifies st_blocks, and the corresponding statx allocation field, as a count in 512-byte units. The separate st_blksize field describes the preferred size for efficient filesystem I/O; it is not the multiplier for that allocation count.

Keep the reporting interface beside the figure. The same documentation warns that POSIX does not fix the st_blocks unit and that other implementations can use different units, potentially by filesystem. A displayed block count without its unit cannot support the byte comparison.

References: [S2]

Work two 2 MiB data intervals around one 6 MiB hole

Consider one fictional, stable regular file with a logical length of exactly 10 MiB. The first data interval runs from offset 0 up to, but excluding, 2 MiB. A hole runs from 2 MiB up to, but excluding, 8 MiB. The second data interval runs from 8 MiB up to, but excluding, the end at 10 MiB. Reading the file produces the first interval's bytes, 6 MiB of zeros, then the second interval's bytes.

Use binary units: 1 MiB equals 1,048,576 bytes. The logical length is therefore 10,485,760 bytes. The data intervals total 2 + 2 = 4 MiB, or 4,194,304 bytes, and the hole spans 6,291,456 bytes.

Stipulate that exactly 4 MiB of data blocks is allocated. Exclude allocation rounding, metadata and other overhead, compression, deduplication and shared extents from this simplified account. The exact allocation is an assumption; the interval lengths alone do not establish a real filesystem's reported total.

With Linux's 512-byte allocation-count unit, 4,194,304 / 512 = 8,192 units. The reconciliation is 4 MiB of stipulated allocated data plus a 6 MiB hole within a 10 MiB logical length. Those 8,192 units are accounting units, not a claim that the filesystem allocates data in individual 512-byte pieces.

References: [U1][S2]

An equal-byte copy can occupy more filesystem space

Now stipulate a second file with exactly the same readable bytes at every offset and the same 10 MiB length. In this dense counterpart, data blocks also hold the middle 6 MiB of zeros. Under the same simplified assumptions, its allocated data totals 10,485,760 bytes, or 10,485,760 / 512 = 20,480 units.

The two files agree on content and length while differing by 20,480 - 8,192 = 12,288 allocation-count units: 6,291,456 bytes. Content equivalence alone cannot identify which allocation layout the destination has. These are stipulated representations, not measured copy results.

The Linux copy_file_range reference supplies a concrete reason to ask about the actual copy path: its notes say copying a sparse file may expand holes. That statement concerns this interface; it predicts neither universal expansion nor universal preservation by copy tools.

An illustrative archive could encode the two data intervals, their offsets and the final logical length, rather than carry the middle zeros literally. Reconstructing the same bytes would still leave destination allocation to resolve; the container's own metadata also prevents treating 4 MiB as its exact size.

References: [C1]

Hole seeking and zero scans answer narrower questions

Linux's SEEK_HOLE and SEEK_DATA operations do not guarantee an exact allocation map. A filesystem can report the whole file as data and the next hole at its end.

Stored zeros need not be holes. Neither a zero scan nor the absence of an interior SEEK_HOLE result establishes the layout. Keep content, hole reports and allocated-block counts as separate evidence.

References: [S1]

Decide what the destination capacity claim must cover

Suppose a fictional artifact handoff lists this file as 10 MiB long and 4 MiB allocated, then proposes 4 MiB of destination space because the copy will preserve every byte. The byte-preservation promise leaves the allocation question open. The stipulated dense counterpart also preserves every byte but requires 10 MiB of allocated data in this example.

Ask the storage owner to identify the destination filesystem, the copy or archive representation and the evidence supporting its allocation treatment. Keep the artifact revision, logical length, allocation unit and observation stage attached to the comparison. Source allocation before transfer, container length and destination allocation after reconstruction are separate quantities.

If the requirement is a readable artifact of the same length and contents, assess that claim directly. If capacity depends on retaining sparse allocation, require evidence for that additional property on the proposed path. The source's smaller count does not supply it.

Carry the file result to the right storage and project owners

File allocation describes filesystem backing. The related thin-storage guide follows the separate volume and pool account; the memory-mapped-model guide follows CPU page residency. Neither file length nor this allocation count establishes thin-pool consumption, NAND usage or unique consumption where extents are shared.

If the capacity review separately leads to storage equipment needing physical installation, Leviathan's rack-and-stack service and project inquiry below cover discussion of agreed mounting, physical IT cabling, labels and installation records. Share a nonconfidential equipment summary, rack positions, connection schedule, site and target window. The appointed storage owner retains filesystem, copy and software acceptance decisions.

References: [L1]