On 1082815924 seconds since the Beginning of the UNIX epoch
"Denis Lagno" wrote:
>

>I am thinking about compressed block device layer -- implemented in much
>the same fashion as cgd/ccd/vnd.
>This layer will use some underlying device and provide virtual block device of
> larger size.

This will end up being a quite complicated driver to write because
you must ensure that single block write occur atomically or you
will break filesystems that use the disk.  This is why cgd encrypts
each block independently and does not do things like storing blocks
of keys or IVs on the disk.  If you do this, then you have to
maintain a journal or some such to ensure that you can either
rollback or rollforward the changes after a crash or the removal
of removable media.  (ISTR that there are even encrypted disks
written recently that get this wrong, which is rather surprising.)

For a compressed disk image, you cannot escape from maintaining a
journal (or some such) on the disk because you are changing the
sizes of the blocks and the blocks that the filesystem thinks will
be written atomically will actually span multiple physical disk
blocks.

It will also be an interesting task to perform allocation while
trying to maintain the locality assumptions that file systems have.
Certainly possible, but it does sound like a reasonable amount of
work.

On the other hand, if you make the image read only you can make
the project substantially easier.  For this you just have to come
up with a structure where you can find the right blocks quickly
and a userland program to generate the disk image.

Anyway, just a few random thoughts on the topic...

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/