On Tue, 29 Mar 2005, Cliff Wright wrote:

> I wanted to have compresion handling similar to what Knoppix has for
> live CD creation. So I modified the vnd driver to also have this
> capability. I am showing what I have done in case others have interest.
> Some questions have come up. The driver code has NOTE 1 which says
> "This uses the VOP_BMAP/VOP_STRATEGY interface to the vnode
> instead of a simple VOP_RDWR.
> We do this to avoid distorting the local buffer cache."
> I used vn_rdwr because it was simpler, so what distortion am I causing?
>  The Knoppix cloop method is to break the file up into blocks
> (64k by default),
> compress each block, and save indexes into the compressed file of where
> these blocks start, and place these indexes near the begining of the
> compressed file. This allows for quick indexing into the compressed file.
> However it does mean a special file format is used. The cloop driver
> places all of these indexes in a memory buffer. I used the same method,
> but wonder if just reading in a few at a time would be better? The
> cloop driver also did a one time allocation of a buffer to hold the
> compressed data block. I also used this method but wonder if the
> use of the buffer pool instead might be better.
>  I added a flag to vnconfig (-z) to indicate the file is a compressed
> file. Although autodection of file format would be nice, I don't
> think this could be compatible with Knoppix cloop files as their
> preamble does not appear to be unique enough. Also note this is all for
> readonly use of the compressed file.
> Patches to 2.0 follow:
>

Hi,

I'm also working on a clconfig and cloop(4) driver to support the
compressed Knoppix format.

Although my approach was not to use vnd, but another pseudo driver
and a configuration program (although this shares some things
with vnd(4)).

I use the cloop-2 format, including the Linux preamble (which
is not used by my clconfig program).

As you already implemented this so far, I'll stop working on the
driver and finally finish my clconfig program.

Now some questions for you/the list:
- Keep this in vnd(4) or create another driver?
- Integrate (my) image creation program (clconfig) in vnconfig or
keep standalone? (We shouldn't use the original one, this was GPL).

Maybe some other idea, not related to the cloop2-format, but
something that might speed things up a bit (perhaps):

My idea 'd be to create something that anlyses the block access
of the filesystem to compress (=which blocks belong together),
then compress these blocks in blockgroups, thus "defragmenting"
the underlying filesystem while compressing and uncompressing
them in larger, contiguous chunks? Hm, will this be worth
working on it? Reasonable speedup? The file would also become
smaller due to less index data (although that souldn't matter
much).

-Florian