Leave the unwritten spans of a formatted image as holes

[MayCXC]

Summary

An image is formatted at the capacity the filesystem it will hold is given, and two of its structures are sized from that capacity and written out empty: the journal, which e2fsprogs convention caps at a gigabyte for a filesystem this large, and the inodes of the table past the ones the image holds. Writing them cost the host a gigabyte of disk for every image unpacked, before any of them held anything. An integration run unpacking twenty images spent twenty gigabytes on the emptiness alone and took the disk out from under the machine.

Both spans read as zero, and so does a hole, so a reader of the image sees the same bytes either way and the host keeps the blocks. The bitmaps of the groups past the ones holding content are already placed this way, so this follows a decision the formatter had already made elsewhere.

The last block of the journal is written rather than sought over, so a journal that does not fit in the image still fails at the point it is created rather than later at the I/O layer.

Motivation and Context

This is the difference between an image costing what it holds and costing what it was sized for. The visible symptom is disk exhaustion during an integration run, but it applies to every unpacked image: a 512 GiB sparse image should not cost a gigabyte before anything is written to it.

No issue filed, since this is an internal formatter change with no API or on-disk format implications: the resulting image is byte-identical to a reader. Happy to open one if the project prefers it recorded.

Testing

• swift build and make check clean.
• swift test: 595 tests in 82 suites passed, rebased onto current main (which now includes fix: efsck searching for external journal #856's efsck change to the same file; no conflict).
• TestEXT4Sparse asserts the formatted image's allocated size, which is what regresses if the spans are written again.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update