> > Has anyone made a compressig VFS layer?  That would be almost ideal here.
> > A 16M file system with compression would be enough to put a lot of functionality in...
> 
> The problem is that our file system layering system really hasn't dealt
> with data caching issues when a file layer generates data. While things
> won't be better under UBC at first, UBC will be the long-term win.

Why mess around with the buffer cache??

I think what we really want here is a compressed vnode device. I'd be
happy with a read-only one because for quite a few applications we can
just union mount over it either MFS or a small uncompressed flash FFS.

The naive version is just like vnd except you mount ramdisk.fs.gz instead
of ramdisk.fs; it rewinds and gunzip's as needed to get the blocks. This
would come in handy for INSTALL_TINY on low-memory machine installs.

A faster version would gzip every 8K or so of the filesystem image, so it
didn't have to rewind the entire file because somebody asked for a block
number smaller than the last one.

Depending on how much RAM you have and how much performance you want,
allocate multiple buffers to cache uncompressed bits in. Now it starts
smelling like the i386-translator hardware in non-intel x86's.

It should be possible to work out how much scratch memory the device
will use, and pre-allocate that during initialization, so we aren't
generating data that has to be managed dynamically.

Todd Whitesel
toddpw @ best.com