Changing filesystem resize patterns

> why not use tar or cpio?

Because it's much slower than a sequential copy from a linear file to a linear block device. The OS and storage devices are highly optimised for efficient/fast sequential data operations, tar/cpio have to do heaps of metadata modifications to create all the small containers (dirents, files, etc) that end up getting spread all over the place (can result in small random metadata writeback IO) before it can do all the data copying. And even the data copy is sub-optimal in that it runs as lots of small discontiguous data writes spread all over the device.

The whole point of using qcow2 as an image transport mechanism is that it ships as a linear file, but the internal format is a set of a offset-based data regions that can be copied directly to the storage. And with image building, the initial qcow2 image will actually be written as ascending offset order regions. IOWs, instead of a single sequential data copy to the block device, it turns it into a sequential image file read and a set of smaller sequential {seek, write} (or pwrite()) operations that are run in ascending address order. That's almost as efficient and fast as a straight linear copy, but it skips both transporting and copying all the empty space in the filesystem image.

IOWs, using qcow2 as a image transport mechanism means we gain sparse image distribution support and we lose almost no performance at the image building stage or the "copy image to storage device" deployment phase. We also gain the ability to efficiently ship near empty 100TB filesystem images containing the container image so they only take up as much space as the existing linear 2GB image technique. Then if we deploy the sparse image to sparse storage devices....

As I said, we already have almost all the pieces we need to solve this whole class of issues once and for all with simple mods to image building, transport, deployment and kernel filesystem accounting.

-Dave.