uint32_t table_size; /* table size, in clusters */
Presumably L1 table size? Or any table size?
Hm. It would be nicer not to require contiguous sectors anywhere. How
about a variable- or fixed-height tree?
Both extents and fancier trees don't fit the philosophy, which is to
keep things straightforward and fast by doing less. With extents and
trees you've got something that looks much more like a full-blown
filesystem. Is there an essential feature or characteristic that QED
cannot provide in its current design?
Is the physical image size always derived from the host file metadata? Is
this always safe?
In my email summarizing crash scenarios and recovery we cover the
bases and I think it is safe to rely on file size as physical image
size. The drawback is that you need a host filesystem and cannot
directly use a bare block device. I think that is acceptable for a
sparse format, otherwise we'd be using raw.