lofi(7D) compression support [PSARC/2007/569 FastTrack timeout 10/08/2007]

[Nicolas Williams]

On Tue, Oct 02, 2007 at 08:34:04AM -0600, Alok Aggarwal wrote:
> On Tue, 2 Oct 2007, Darren Moffat wrote:
> >DJM-0 I don't quite understand how this is used.
> >
> >It seems that the process is like this:
> >
> >Create some image file that has a filesystem on it, lets make it UFS.
> >
> ># mkfile 1g /path/to/backingfile.img
> ># lofiadm -C gzip /path/to/backingfile.img
> ># lofiadm -a /path/to/backingfile.img
> >/dev/lofi/1
> ># mkfs -F ufs /dev/rlofi/1
> >...
> ># mount -F ufs /dev/lofi/1 /mnt
> >
> >Is that correct ?
> >
> >In otherwords unlike the crypto case, and what your man page synopsis 
> >suggests, the -C/-s arguments aren't things you pass in when you do a 
> >mapping with -a but instead they are auxiliary functions.
> 
> Correct.

Further, this is all read-only -- no on-the-fly compression takes place,
right?

If so then Darren's example can't be correct, but instead it should be
this:

# lofiadm -a /path/to/backingfile.img
/dev/lofi/1
# mkfs -F ufs /dev/rlofi/1
# mount -F ufs /dev/lofi/1 /mnt
...
# umount /mnt
# lofiadm -d /dev/rlofi/1
# lofiadm -C gzip /path/to/backingfile.img
# lofiadm -a /path/to/backingfile.img
/dev/lofi/1
# mount -F ufs /dev/lofi/1 /mnt

Also, if compressed lofi devices are read-only then the answer to DJM-1
is fairly obvious [to me, though perhaps also wrong].  See below.

> >DJM-1 How does this interact with lofi crypto ?
> >
> >(http://opensolaris.org/os/community/arc/caselog/2007/001/)
> >
> >Which happens first crypto or compression (hint it needs to be compression 
> >otherwise it is waste of CPU resource) ?
> >
> >However if my understanding of how -C and -U work it seems that the 
> >compression would be happening after encryption because by design it isn't 
> >on the fly but actually a distinct admin action (which for building LiveCD 
> >images is fine).

Since compression is a one-time task for a read-only lofi file, then so
should encryption be a one-time task to be done along with (after)
compression:

# lofiadm -a /path/to/backingfile.img
/dev/lofi/1
# mkfs -F ufs /dev/rlofi/1
# mount -F ufs /dev/lofi/1 /mnt
...
# umount /mnt
# lofiadm -c aes128-cbc -e /etc/.../backingfile.key -C gzip /path/to/backingfile.img
# lofiadm -a -c aes128-cbc -k /etc/.../backingfile.key /path/to/backingfile.img
...

OR, perhaps, since there'd now be a header where to store the name of
the cipher used:

...
# lofiadm -c aes128-cbc -e /etc/.../backingfile.key -C gzip /path/to/backingfile.img
# lofiadm -a -k /etc/.../backingfile.key /path/to/backingfile.img
...

Maybe even the -k option could be optional in lofiadm -a ...

> >DJM-5 How big is the header section ?
> 
> It is 12 bytes plus the length of compression algorithm used.
> So, for gzip, it would be 16 bytes (12 + 4).
> 
> >The project to add encryption to lofi stalled on exactly the issue of the 
> >adding metadata to the image.  Since this project is adding a header 
> >section it seems to make sense that the crypto and compression projects 
> >share a metadata section.
> 
> We should talk on this point, it does make sense to
> have a shared metadata section.

I agree.  More persistent information stored in metadata == less for the
sysadmin to remember to repeat in subsequent lofiadm incantantions ==
less trouble.

Nico
--