|
Replies:
12
-
Last Post:
Oct 5, 2007 1:02 PM
by: aalok
|
|
|
|
|
|
|
lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 8:47 AM
|
|
[No Body]
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 8:47 AM
in response to: Guest
|
|
Nicolas Williams wrote:
> 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:
but that isn't how lofi encryption is designed to work, and making it
work like that completely defeat the whole purpose of why do are doing
encryption in lofi. It also creates a window where the data is stored
on disk in the clear - which is exactly what we don't want. It would
also mean we couldn't use lofi with encryption to swap on (which we need
until we get a proper encrypting VM system).
--
Darren J Moffat
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
3,468
From:
US
Registered:
6/15/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 8:50 AM
in response to: darrenm
|
|
On Tue, Oct 02, 2007 at 04:47:08PM +0100, Darren J Moffat wrote:
> Nicolas Williams wrote:
> >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:
>
> but that isn't how lofi encryption is designed to work, and making it
> work like that completely defeat the whole purpose of why do are doing
> encryption in lofi. It also creates a window where the data is stored
> on disk in the clear - which is exactly what we don't want.
Yes, it doesn't seem worthwhile to support one-time compression +
encryption in lofi.
The crucial thing though is that compressed lofi images are read-only.
> It would
> also mean we couldn't use lofi with encryption to swap on (which we need
> until we get a proper encrypting VM system).
Well, you couldn't compress swap using this case because the compression
step is a one-time step and lofiadm -a of compressed images results in
read-only devices!
Nico
--
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
466
From:
US
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 9:11 AM
in response to: nico
|
|
Darren and I talked about the areas of overlap between
lofi encryption and lofi compression. Here's a summary
of what we talked about -
Compressed lofi images are read-only so it makes sense
to allow either compression or encryption on an image
but not both at the same time.
So, lofi compression should be able to spot an
encrypted image and prevent compression. Likewise, lofi
encryption should be able to spot a compressed image
and prevent encryption.
This obviates the need for on-disk metadata to be stored
by lofi encryption.
In other words, there is a dependancy between PSARC/2007/001 and
this case. The two project teams will work together to
make sure that encrypted images can't be compressed and vice
versa.
Also, I need to make it clear in the documentation that
compressed lofi images can be read-only and not read/write.
Alok
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
466
From:
US
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 4, 2007 3:15 PM
in response to: aalok
|
|
Here's an updated spec (diffs followed by the actual
spec), Tim will be updating the case materials as
well.
Alok
--
------- clofi.psarc -------
--- /tmp/geta7790 Thu Oct 4 16:05:24 2007
+++ /tmp/getb7790 Thu Oct 4 16:05:24 2007
@@ -20,11 +20,12 @@
This project aims to extend lofi(7D) to support reading from a
compressed file via on-the-fly decompression.
This project will also add extensions to the lofiadm(1M) command to
provide for the ability to compress a file in a suitable format
- and to decompress it entirely.
+ and to decompress it entirely. The ability to decompress is provided
+ for debugging purposes.
Design Overview
The basic design is to compress a file in fixed size segments and
store the segments sequentially. The information about where each
@@ -38,10 +39,15 @@
structure. The compression metadata thus read is then used to
decompress the requested data when a read request comes in.
If the decompression fails for some reason, an EIO
is returned.
+ It should be noted that a compressed file can only be
+ accessed in a read-only mode and no changes are allowed to it
+ once it is compressed. An attempt to access the file in read/write
+ or mount it in read/write mode will fail with an ENOTSUP.
+
On disk format
A graphic representation of the compression header stored at the
start of the file can be found under materials/ondisk_format.png
@@ -54,10 +60,20 @@
On the fly decompression
A graphic representation of reading from compressed versus regular
files can be found under materials/compress_io.jpg
+Interaction with lofi encryption
+
+ PSARC/2007/001 proposes to add encryption to lofi(7D). Since
+ compressed lofi images are read-only, it makes sense to allow
+ either compression or encryption on a file but not both at
+ the same time.
+
+ Depending upon when PSARC/2007/001 delivers, support will need
+ to be added to prevent compressing encrypted files and vice-versa.
+
Compression Algorithms
The lofi(7D) driver will support compression algorithms present
in the Solaris kernel. Currently, lzjb and gzip are the two
algorithms available.
@@ -65,13 +81,14 @@
The lzjb algorithm provides very fast compression as compared
to gzip. gzip, even though it is slower than lzjb, is fast
enough for the typical use case of a LiveCD. In addition, gzip
provides a much better compression ratio as compared to lzjb
(on the order of ~25% in some cases) and it allows for more data
- to be packed on to the media. These characteristics make gzip
- well suited for a LiveCD. Thus, gzip will be the only supported
- algorithm at this time.
+ to be packed on to the media. These characteristics make gzip,
+ specifically gzip level 9, well suited for a LiveCD. Thus, gzip
+ will be the only supported algorithm at this time with levels 6
+ and 9 being supported. gzip level 6 will be the default.
The changes being made as part of this project will allow for
compression algorithms to be plugged into lofi with relative
ease as more of these algorithms are made available in the
Solaris kernel.
@@ -78,40 +95,44 @@
Command Changes
lofiadm(1M) will take the following additional arguments -
- -C Compress the file with a specified compression algorithm
- or with the default compression algorithm if one isn't
- specified. The only supported compression algorithm at this
- time is gzip which is also the default.
+ -C gzip | gzip-N Compress the file with "gzip" compression
+ algorithm before mapping the file in. You can
+ specify the "gzip" level by using the value
+ "gzip-N" where N is 6 (fast) or 9 (best compression
+ ratio). Currently, "gzip" is equivalent to "gzip-6"
+ (which is also the default for zfs(1M) and gzip(1)).
- -s The segment size to use to divide the file being compressed.
- If no segment size is specified, a default segment size of
- 128k is used.
+ -s segsize The segment size to use to divide the file being
+ compressed. Segment size must be an integer
+ multiple of 512.
-U Uncompress a compressed file
The output of lofiadm(1M) will also change to add another field to
reflect if the mapped file(s) is a compressed file or a regular file.
Examples:
- 1. Compress a file with gzip
+ 1. Compress a file with gzip and add the compressed file as a block
+ device
- # lofiadm -C gzip /export/home/solaris.iso
+ # lofiadm -a -C gzip /export/home/solaris.iso
- 2. Compress a file with gzip and compress it in 64k chunks
+ 2. Compress a file with gzip in 64k chunks and add the compressed
+ file as a block device
# lofiadm -C gzip -s 64k /export/home/solaris.iso
3. Check if there are any compressed files that are mapped
# lofiadm
- Block Device File Type
+ Block Device File Options
/dev/lofi/1 /export/home/solaris.iso Compressed (gzip)
- /dev/lofi/2 /export/home/regular.iso Regular
+ /dev/lofi/2 /export/home/regular.iso -
4. Uncompress a compressed file
# lofiadm -U /export/home/solaris.iso
---
clofi.psarc 1.3 07/10/04 SMI
Template Version: @(#)sac_nextcase 1.3 10/04/07 SMI
1. Introduction
1.1 Project/Component Working Name:
lofi(7D) compression support
1.2 Name of Document Author/Supplier
Author: Alok Aggarwal
1.3 Date of this Document
28 September, 2007
4. Technical Description
There are cases where certain files containing a file system image
need to be compressed. A classic use case is that of a LiveCD.
Compression support in lofi is required to make LiveCDs practical.
It allows for more data to be packed on the media and improves
performance by reducing head seek times.
This project aims to extend lofi(7D) to support reading from a
compressed file via on-the-fly decompression.
This project will also add extensions to the lofiadm(1M) command to
provide for the ability to compress a file in a suitable format
and to decompress it entirely. The ability to decompress is provided
for debugging purposes.
Design Overview
The basic design is to compress a file in fixed size segments and
store the segments sequentially. The information about where each
of the segments start is maintained in an index. This index along
with a header that contains the compression algorithm used,
segment size, number of segments and the uncompressed size of the
last segment is stored at the start of the file.
When a compressed file is mapped, the header containing the
compression metadata is read in and stored in the lofi state
structure. The compression metadata thus read is then used to
decompress the requested data when a read request comes in.
If the decompression fails for some reason, an EIO
is returned.
It should be noted that a compressed file can only be
accessed in a read-only mode and no changes are allowed to it
once it is compressed. An attempt to access the file in read/write
or mount it in read/write mode will fail with an ENOTSUP.
On disk format
A graphic representation of the compression header stored at the
start of the file can be found under materials/ondisk_format.png
It should be noted that this header information is always stored
in network byte order. This allows for endian neutral filesystems
such as ZFS to be compressed on a little endian machine, and
subsequently be uncompressed on a big endian machine; and
vice-versa.
On the fly decompression
A graphic representation of reading from compressed versus regular
files can be found under materials/compress_io.jpg
Interaction with lofi encryption
PSARC/2007/001 proposes to add encryption to lofi(7D). Since
compressed lofi images are read-only, it makes sense to allow
either compression or encryption on a file but not both at
the same time.
Depending upon when PSARC/2007/001 delivers, support will need
to be added to prevent compressing encrypted files and vice-versa.
Compression Algorithms
The lofi(7D) driver will support compression algorithms present
in the Solaris kernel. Currently, lzjb and gzip are the two
algorithms available.
The lzjb algorithm provides very fast compression as compared
to gzip. gzip, even though it is slower than lzjb, is fast
enough for the typical use case of a LiveCD. In addition, gzip
provides a much better compression ratio as compared to lzjb
(on the order of ~25% in some cases) and it allows for more data
to be packed on to the media. These characteristics make gzip,
specifically gzip level 9, well suited for a LiveCD. Thus, gzip
will be the only supported algorithm at this time with levels 6
and 9 being supported. gzip level 6 will be the default.
The changes being made as part of this project will allow for
compression algorithms to be plugged into lofi with relative
ease as more of these algorithms are made available in the
Solaris kernel.
Command Changes
lofiadm(1M) will take the following additional arguments -
-C gzip | gzip-N Compress the file with "gzip" compression
algorithm before mapping the file in. You can
specify the "gzip" level by using the value
"gzip-N" where N is 6 (fast) or 9 (best compression
ratio). Currently, "gzip" is equivalent to "gzip-6"
(which is also the default for zfs(1M) and gzip(1)).
-s segsize The segment size to use to divide the file being
compressed. Segment size must be an integer
multiple of 512.
-U Uncompress a compressed file
The output of lofiadm(1M) will also change to add another field to
reflect if the mapped file(s) is a compressed file or a regular file.
Examples:
1. Compress a file with gzip and add the compressed file as a block
device
# lofiadm -a -C gzip /export/home/solaris.iso
2. Compress a file with gzip in 64k chunks and add the compressed
file as a block device
# lofiadm -C gzip -s 64k /export/home/solaris.iso
3. Check if there are any compressed files that are mapped
# lofiadm
Block Device File Options
/dev/lofi/1 /export/home/solaris.iso Compressed(gzip)
/dev/lofi/2 /export/home/regular.iso -
4. Uncompress a compressed file
# lofiadm -U /export/home/solaris.iso
References
PSARC/2007/492 - Project Indiana
http://sac.eng/PSARC/2007/492/discussion.materials/Indiana.txt
PSARC/1999/463 - lofi
http://sac.sfbay/Archives/CaseLog/arc/PSARC/1999/463
On the Fly Decompression in BeleniX
http://www.genunix.org/distributions/belenix_site/?q=compression
gzip for ZFS update
http://blogs.sun.com/ahl/entry/gzip_for_zfs_update
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
1,223
From:
India
Registered:
7/15/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 4, 2007 9:55 PM
in response to: aalok
|
|
Alok Aggarwal wrote:
> [...] Examples:
>
> - 1. Compress a file with gzip
> + 1. Compress a file with gzip and add the compressed file as a block
> + device
>
> - # lofiadm -C gzip /export/home/solaris.iso
> + # lofiadm -a -C gzip /export/home/solaris.iso
>
> - 2. Compress a file with gzip and compress it in 64k chunks
> + 2. Compress a file with gzip in 64k chunks and add the compressed
> + file as a block device
>
> # lofiadm -C gzip -s 64k /export/home/solaris.iso
>
Shouldn't this be:
lofiadm -a -C gzip -s 64k /export/home/solaris.iso
?
On the other hand, what will be the name of the compressed file ?
Would it remain as the original filename ? Can cause confusion.
What happens to the compressed file when it is unmapped ?
The process of compression is a very time consuming task, probably
on the order of 30 - 50mins for 2GB worth of data, because it is
chunked compression (though this can be improved by some
parallelization and buffering techniques). So IMHO it is less
confusing to do something like this:
lofiadm -C gzip -s 64k /export/home/solaris.iso
Produces solaris.iso.<ext> compressed file.
lofiadm -a /export/home/solaris.iso.<ext>
Maps the compressed file.
lofiadm Outputs:
Block Device File Options
/dev/lofi/1 /export/home/solaris.iso.<ext> Compressed (gzip)
/dev/lofi/2 /export/home/regular.iso.<ext> -
Semantically similar to using gzip or any other compression utility
for that matter.
Regards,
Moinak.
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
466
From:
US
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 5, 2007 6:58 AM
in response to: moinakg
|
|
On Fri, 5 Oct 2007, Moinak Ghosh wrote:
> Alok Aggarwal wrote:
>> [...] Examples:
>>
>> - 1. Compress a file with gzip
>> + 1. Compress a file with gzip and add the compressed file as a block
>> + device
>>
>> - # lofiadm -C gzip /export/home/solaris.iso
>> + # lofiadm -a -C gzip /export/home/solaris.iso
>>
>> - 2. Compress a file with gzip and compress it in 64k chunks
>> + 2. Compress a file with gzip in 64k chunks and add the compressed
>> + file as a block device
>>
>> # lofiadm -C gzip -s 64k /export/home/solaris.iso
>>
>
> Shouldn't this be:
>
> lofiadm -a -C gzip -s 64k /export/home/solaris.iso
> ?
It should be, it's a typo.
> On the other hand, what will be the name of the compressed file ?
> Would it remain as the original filename ? Can cause confusion.
The name of the file remains the same. Why will it cause
confusion?
If you start adding extensions such as .gz to the compressed
file, what's stopping a user from running gunzip(1) or your
favorite decompression utility on that file and getting
disappointed to see it fail.
The key is that a file compressed with lofiadm is useful
only within the context of lofi(7D) and not outside it.
Not adding an extension just reinforces that point.
> What happens to the compressed file when it is unmapped ?
If it wasn't explicitly uncompressed by the user it stays
compressed.
> The process of compression is a very time consuming task, probably
> on the order of 30 - 50mins for 2GB worth of data, because it is
> chunked compression (though this can be improved by some
> parallelization and buffering techniques). So IMHO it is less
> confusing to do something like this:
>
> lofiadm -C gzip -s 64k /export/home/solaris.iso
> Produces solaris.iso.<ext> compressed file.
>
> lofiadm -a /export/home/solaris.iso.<ext>
> Maps the compressed file.
>
> lofiadm Outputs:
>
> Block Device File Options
> /dev/lofi/1 /export/home/solaris.iso.<ext> Compressed (gzip)
> /dev/lofi/2 /export/home/regular.iso.<ext> -
>
>
> Semantically similar to using gzip or any other compression utility
> for that matter.
The original proposal had what you're suggesting, i.e.
"compress this file with -C" and "map this compressed file
with -a" as a two step process. As part of some offline
discussions it was suggested that having these two actions
as disjoint steps doesn't buy us anything.
If a user compresses a file with lofiadm, in all certainity
he's bound to map that compressed file as a logical next step
so why not just enable him to do that in a single command
invocation.
Apropos making compression a separate step so the user doesn't
wonder if the command is hung, the lofiadm output will change
to printing something like this to stderr (so scripts don't
break) -
# lofiadm -a -C gzip -s 64k /export/home/solaris.iso
Compressing solaris.iso
Mapping solaris.iso
/dev/lofi/1
I had meant to add this to the updated spec but apparently
missed it.
Alok
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 5, 2007 7:15 AM
in response to: aalok
|
|
Alok Aggarwal wrote:
> On Fri, 5 Oct 2007, Moinak Ghosh wrote:
>
>> Alok Aggarwal wrote:
>>> [...] Examples:
>>>
>>> - 1. Compress a file with gzip
>>> + 1. Compress a file with gzip and add the compressed file as a block
>>> + device
>>>
>>> - # lofiadm -C gzip /export/home/solaris.iso
>>> + # lofiadm -a -C gzip /export/home/solaris.iso
>>>
>>> - 2. Compress a file with gzip and compress it in 64k chunks
>>> + 2. Compress a file with gzip in 64k chunks and add the compressed
>>> + file as a block device
>>>
>>> # lofiadm -C gzip -s 64k /export/home/solaris.iso
>>>
>> Shouldn't this be:
>>
>> lofiadm -a -C gzip -s 64k /export/home/solaris.iso
>> ?
>
> It should be, it's a typo.
Now I'm really confused. I thought that the -C was done while there was
no mapping in place, but -a adds a mapping.
> The original proposal had what you're suggesting, i.e.
> "compress this file with -C" and "map this compressed file
> with -a" as a two step process. As part of some offline
> discussions it was suggested that having these two actions
> as disjoint steps doesn't buy us anything.
So how long does the compress take ? If it is anything more than a few
seconds I think it should be a separate step because -a has always been
near instant.
> If a user compresses a file with lofiadm, in all certainity
> he's bound to map that compressed file as a logical next step
> so why not just enable him to do that in a single command
> invocation.
I don't think that follows, in fact given that one of the main
motivations for this project is building compressed LiveCD images I'd
have expected that it wouldn't be getting mapped immediately afterwards.
It also incorrectly leads the user into thinking that compression is on
the fly which it is not.
> Apropos making compression a separate step so the user doesn't
> wonder if the command is hung, the lofiadm output will change
> to printing something like this to stderr (so scripts don't
> break) -
> # lofiadm -a -C gzip -s 64k /export/home/solaris.iso
> Compressing solaris.iso
> Mapping solaris.iso
> /dev/lofi/1
You really shouldn't do that the output of lofiadm -a is intended to be
scriptable and even says so in the man page:
The ability to specify a device is pro-
vided for use in scripts that wish to
re-establish a particular set of asso-
ciations.
The other problem with -C being part of the mapping is it is now
different from the -U option to uncompress since you wouldn't do lofiadm
-d -U
--
Darren J Moffat
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
466
From:
US
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 5, 2007 1:02 PM
in response to: darrenm
|
|
On Fri, 5 Oct 2007, Darren J Moffat wrote:
> Alok Aggarwal wrote:
>> On Fri, 5 Oct 2007, Moinak Ghosh wrote:
>>
>>> Alok Aggarwal wrote:
>>>> [...] Examples:
>>>>
>>>> - 1. Compress a file with gzip
>>>> + 1. Compress a file with gzip and add the compressed file as a block
>>>> + device
>>>>
>>>> - # lofiadm -C gzip /export/home/solaris.iso
>>>> + # lofiadm -a -C gzip /export/home/solaris.iso
>>>>
>>>> - 2. Compress a file with gzip and compress it in 64k chunks
>>>> + 2. Compress a file with gzip in 64k chunks and add the compressed
>>>> + file as a block device
>>>>
>>>> # lofiadm -C gzip -s 64k /export/home/solaris.iso
>>>>
>>> Shouldn't this be:
>>>
>>> lofiadm -a -C gzip -s 64k /export/home/solaris.iso
>>> ?
>>
>> It should be, it's a typo.
>
> Now I'm really confused. I thought that the -C was done while there was no
> mapping in place, but -a adds a mapping.
>
>> The original proposal had what you're suggesting, i.e.
>> "compress this file with -C" and "map this compressed file
>> with -a" as a two step process. As part of some offline
>> discussions it was suggested that having these two actions
>> as disjoint steps doesn't buy us anything.
>
> So how long does the compress take ? If it is anything more than a few
> seconds I think it should be a separate step because -a has always been near
> instant.
Yes, it takes a while to compress and depends on the
size of the file being compressed.
>> If a user compresses a file with lofiadm, in all certainity
>> he's bound to map that compressed file as a logical next step
>> so why not just enable him to do that in a single command
>> invocation.
>
> I don't think that follows, in fact given that one of the main motivations
> for this project is building compressed LiveCD images I'd have expected that
> it wouldn't be getting mapped immediately afterwards.
>
> It also incorrectly leads the user into thinking that compression is on the
> fly which it is not.
How does supporting both flavors of the command line
sound? That is -
# lofiadm -C gzip -s 64k /export/home/solaris.iso <-- compress the file
Or, optionally,
# lofiadm -a -C gzip -s 64k /e> Apropos making compression a separate step so the user doesn't
>> wonder if the command is hung, the lofiadm output will change
>> to printing something like this to stderr (so scripts don't
>> break) -
>
>
>> # lofiadm -a -C gzip -s 64k /export/home/solaris.iso
>> Compressing solaris.iso
>> Mapping solaris.iso
>> /dev/lofi/1
>
> You really shouldn't do that the output of lofiadm -a is intended to be
> scriptable and even says so in the man page:
>
> The ability to specify a device is pro-
> vided for use in scripts that wish to
> re-establish a particular set of asso-
> ciations.
Will the scripts still break if the new messages "Compressing
file" and "Mapping file" are sent to *stderr* though?
"/dev/lofi/1" still goes to stdout so there should be no
difference from the scripts' perspective.
> The other problem with -C being part of the mapping is it is now different
> from the -U option to uncompress since you wouldn't do lofiadm -d -U
Supporting both forms of the command line should take care
of this.
Alok
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Gary Winiger
gww@eng.sun.com
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 10:17 AM
in response to: Guest
|
|
> Darren and I talked about the areas of overlap between
> lofi encryption and lofi compression. Here's a summary
> of what we talked about -
>
> Compressed lofi images are read-only so it makes sense
> to allow either compression or encryption on an image
> but not both at the same time.
I can understand doing both may be ETOOHARD or
ENOTWORTHIT, and I don't see why it isn't architecturally
correct to compress then encrypt/decrypt then expand.
> So, lofi compression should be able to spot an
> encrypted image and prevent compression. Likewise, lofi
> encryption should be able to spot a compressed image
> and prevent encryption.
>
> This obviates the need for on-disk metadata to be stored
> by lofi encryption.
So ENOTWORTHIT?
> Also, I need to make it clear in the documentation that
> compressed lofi images can be read-only and not read/write.
This seems to me to be a change from the original
proposal. Have I missed something, or has the proposal
changed?
Gary..
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
3,871
From:
GB
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 10:26 AM
in response to: Gary Winiger
|
|
Gary Winiger wrote:
>> Darren and I talked about the areas of overlap between
>> lofi encryption and lofi compression. Here's a summary
>> of what we talked about -
>>
>> Compressed lofi images are read-only so it makes sense
>> to allow either compression or encryption on an image
>> but not both at the same time.
>
> I can understand doing both may be ETOOHARD or
> ENOTWORTHIT, and I don't see why it isn't architecturally
> correct to compress then encrypt/decrypt then expand.
ENOTWORTHIT because we already have compression support in ZFS and
crypto is being added in such away that we *will* be able to compress
then encrypt (decrypt then decompress).
--
Darren J Moffat
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Posts:
466
From:
US
Registered:
3/9/05
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 11:03 AM
in response to: Gary Winiger
|
|
On Tue, 2 Oct 2007, Gary Winiger wrote:
>> Also, I need to make it clear in the documentation that
>> compressed lofi images can be read-only and not read/write.
>
> This seems to me to be a change from the original
> proposal. Have I missed something, or has the proposal
> changed?
It was a case of me having missed specifying
this in the case materials.
Basically, this case provides "offline" compression
if you will; compressing a file and mapping that file
via lofi are two separate steps.
If we were to provide read/write access to compressed
files, we'd essentially have to provide on-the-fly
compression. There doesn't seem to be a need to provide
such a facility.
Alok
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
Gary Winiger
gww@eng.sun.com
|
|
|
|
Re: lofi(7D) compression support [PSARC/2007/569
FastTrack timeout 10/08/2007]
Posted:
Oct 2, 2007 10:30 AM
in response to: Guest
|
|
> ENOTWORTHIT because we already have compression support in ZFS and
> crypto is being added in such away that we *will* be able to compress
> then encrypt (decrypt then decompress).
Fine with me.
Gary..
_______________________________________________
caiman-discuss mailing list
caiman-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
|
|
|
|
|
