memstick.img is bloated with 7% 2K blocks of nulls

[Tim Kientzle]

On Feb 11, 2011, at 11:09 AM, Julian H. Stacey wrote:

> memstick.img wastes 7% with 2K blocks of nulls.
> shown by:
> 	8f -b 0 -n 2048 -l -f Fr*
> 	http://berklix.com/~jhs/src/bsd/jhs/bin/public/8f/	8f.c 8f.1
> 
> ...
> The CD & DVD images are not nearly so wasteful, see above.
> As near 1G ( 959467520 FreeBSD-8.2-RC3-i386-memstick.img ) it will
> soon not fit on 1G sticks.

There is a big difference between laying out a read-only filesystem
and laying out a read-write disk image.  CD/DVD writers do pack
file contents one after the other on the image.  The current UFS code
is designed to leave enough "slack space" to support future
file writes.

The strategy used by libarchive's recent ISO writer
is to concatenate the file bodies into a temp file
(with minimal padding between entries to meet alignment
requirements) while storing directory information
in memory.  The final output then consists of the
directory information followed by the concatenated
file bodies.

I suspect a similar strategy could be used to lay out
and write a read-only optimized UFS image.
A few folks have asked about a UFS writer for
libarchive; I think it's probably feasible but I doubt
very much of the existing UFS code can be recycled
for such a project.

Alternatively, of course, is there any way to use
isofs instead of ufs for memstick.img?

Tim