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. 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). DJM-2 What is the guidance for changing the segment size ? DJM-3 What happens if I make an lofi mapping with the default segment size and later map the same file with a different size ? DJM-4 What is the minimum segment size ? DJM-5 How big is the header section ? 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. DJM-6 How big is the index section ? DJM-7 In the ZFS use of gzip it is possible to specify the level with gzip-6 being the default. I think this case should do the same. DJM-8 The encrypted lofi case also proposed to add a new column to the output to indicate if the mapping was encrypted, since this case also adds a new column, coordination is needed (I think we are okay here though). Process issue: http://opensolaris.org/os/community/arc/caselog/2007/569/ gives 404 at the moment. -- Darren J Moffat
