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 --
