Subject: Re: Added compression handling to vnd driver
To: Florian Stoehr <netbsd@wolfnode.de>
From: Cliff Wright <cliff@snipe444.org>
List: tech-kern
Date: 03/29/2005 18:32:01
On Tue, 29 Mar 2005 23:22:35 +0200 (CEST)
Florian Stoehr <netbsd@wolfnode.de> wrote:

> - Integrate (my) image creation program (clconfig) in vnconfig or
> keep standalone? (We shouldn't use the original one, this was GPL).
> 
Ah my big missing piece. I did not want to submit a GPL'd either.
I think it should be stand alone, as its function is different.
One thing I noticed about the create_compressed_fs program is that
it was normally used at the end of a mkisofs pipe, so the size
of the data was not known untill all the data had passed through
the pipe. This meant the space needed for the block pointers is not
known until all the data has been seen. So for Knoppix all 720MB
of data was held in memory untill the end so he could then write the
block pointers followed by the data. I had to up my datasize limit
to handle this. I think a method to not tie up this amount of memory
would be nice. Maybe a temp file to hold the block pointers that
are then concatenated at the end.

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

The order of files can be specified to mkisofs. Klaus had created a file
that had this order to try to improve performance. He made a comment
that he did not think the improvement was that great.

It was pointed out that I did not include the man page change for
vnconfig. Here at least is an example of usage:

vnconfig -z vnd0 /cdrom/KNOPPIX/KNOPPIX
mount -t cd9660 /dev/vnd0a /mnt

The file /cdrom/KNOPPIX/KNOPPIX is the compressed file. Since the file
is not a gzip file, maybe -z is the wrong letter to use, as it generally
implies a gzip file. 
Is their a better?