In message: <20100304102158.ga8...@nobby.geeknest.org>
Ulf Lilleengen writes:
: On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
: > Hi,
: > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
in connection with this is an issue be
On Thu, Mar 04, 2010 at 04:38:31PM +0200, Alexandr Rybalko wrote:
> On Thu, 4 Mar 2010 15:28:19 +0100
> Joerg Sonnenberger wrote:
>
> >> On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
> >> > LZMA compression optimized for fast decompression.
> >>
> >> It is still measurable sl
On Thu, Mar 04, 2010 at 03:54:05PM +0100, Dimitry Andric wrote:
> On 2010-03-04 15:28, Joerg Sonnenberger wrote:
> >It is still measurable slower than gzip and it is certainly not free.
>
> Ehm, the LZMA SDK is in the public domain, how much more "free" would
> you want it?
Free as in "time it ta
On 2010-03-04 15:28, Joerg Sonnenberger wrote:
It is still measurable slower than gzip and it is certainly not free.
Ehm, the LZMA SDK is in the public domain, how much more "free" would
you want it?
___
freebsd-hackers@freebsd.org mailing list
http:/
On Thu, 4 Mar 2010 15:28:19 +0100
Joerg Sonnenberger wrote:
>> On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
>> > LZMA compression optimized for fast decompression.
>>
>> It is still measurable slower than gzip and it is certainly not free.
>> Most hard disks have linear read
On Thu, Mar 04, 2010 at 12:17:05PM +0200, Alexandr Rybalko wrote:
> LZMA compression optimized for fast decompression.
It is still measurable slower than gzip and it is certainly not free.
Most hard disks have linear read times >> 10 MB/s but the decompression
can easily need half a second even on
On Thu, 4 Mar 2010 11:21:59 +0100
Ulf Lilleengen wrote:
>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with
>> > lzma), in connection with this is an issue bes
On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> in connection with this is an issue best left lzma
> code in the file "geom_ulzma.c" or store lzma library separately.
ge than to wait for 24MB from
>> > disk.
>>
>> Linear reads from disk are fast. :) Linear reads from the SPI flash
>> are slower; and I think the decompression phase is quite a bit slower.
>>
>> I'll investigate all of this further once I've played
PI flash
are slower; and I think the decompression phase is quite a bit slower.
I'll investigate all of this further once I've played with GEOM_ULZMA.
Adrian
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listi
t;> The answer is "whoa". 24 megabyte compressed kernel + MDROOT drops to
>> 6.5 megabytes with gzip -9 and a few bytes shy of 5 megabytes with a
>> default lzma compress.
>>
>> .. wow. :)
>>
>> This is +1 for GEOM_ULZMA too if it's as effective
On Wed, 3 Mar 2010 07:35:55 +0100
Pawel Jakub Dawidek wrote:
>> On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
>> > On 2010-03-02 09:47, Alexandr Rybalko wrote:
>> > >>>Definiatelly separately, not sure where. There is ongoing discussion
>> > >>>somwhere on importing this algorit
On Wed, Mar 03, 2010 at 08:29:14AM -0800, Tim Kientzle wrote:
> Adrian Chadd wrote:
> >On 21 February 2010 02:20, Adrian Chadd wrote:
> >>Oh I know that! I'm just saying that I may try lzma'ing the kernel and
> >>rootfs's to see what kind of savings I get over gzip. :)
> >
> >The answer is "whoa".
.5 megabytes with gzip -9 and a few bytes shy of 5 megabytes with a
default lzma compress.
Interesting question: What is the impact on boot speed?
It could be a lot faster to load 5MB from disk and
decompress to a 24MB image than to wait for 24MB from
disk.
This is +1 for GEOM_ULZMA too if it&#
ith gzip -9 and a few bytes shy of 5 megabytes with a
default lzma compress.
.. wow. :)
This is +1 for GEOM_ULZMA too if it's as effective for the mfs itself.
I'll toy with that later.
Adrian
___
freebsd-hackers@freebsd.org mailing list
On Tue, Mar 02, 2010 at 08:32:20PM +0100, Dimitry Andric wrote:
> On 2010-03-02 09:47, Alexandr Rybalko wrote:
> >>>Definiatelly separately, not sure where. There is ongoing discussion
> >>>somwhere on importing this algorithm to the base for tar(1) to use, it
> >>>would be best to have only one co
On Tue, 02 Mar 2010 20:32:20 +0100
Dimitry Andric wrote:
> On 2010-03-02 09:47, Alexandr Rybalko wrote:
> >>> Definiatelly separately, not sure where. There is ongoing discussion
> >>> somwhere on importing this algorithm to the base for tar(1) to use, it
> >>> would be best to have only one copy
On 2010-03-02 09:47, Alexandr Rybalko wrote:
Definiatelly separately, not sure where. There is ongoing discussion
somwhere on importing this algorithm to the base for tar(1) to use, it
would be best to have only one copy of code in the tree.
I have already said, that it would be good for embedde
Hi,
On Tue, 2 Mar 2010 08:17:36 +0100
Pawel Jakub Dawidek wrote:
>> On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
>> > Hi,
>> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with
>> > lzma), [...]
>>
>> Wo
On Fri, Feb 19, 2010 at 04:36:44PM +0200, Alexandr Rybalko wrote:
> Hi,
> I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> [...]
Wouldn't it be better to modify geom_uzip to be universal decompression
class with various algorithms implemented as pl
I see no reason to not import the current
version [of liblzma and xz] into the FreeBSD base system. I plan
to do so but may not get to it very soon; I
certainly would not complain if someone else
beat me to it. ;-)
Thanks for that info.
GEOM_ULZMA contain two parts mkulzma and GEOM module
r portability
> fixes. I see no reason to not import the current
> version into the FreeBSD base system. I plan
> to do so but may not get to it very soon; I
> certainly would not complain if someone else
> beat me to it. ;-)
>
> There are other lzma libraries around, of c
>> The code organization depends on what you want to do with it and how you
>> want to update the code in the future, if your lzma library is third party.
>
>LZMA made by Igor Pavlov, and since 4.62 it licensed under Public Domain.
>So we can use it, if we need.
>
>>
>> If you never intend to updat
b. f. wrote:
The code organization depends on what you want to do with it and how you
want to update the code in the future, if your lzma library is third party.
LZMA made by Igor Pavlov, and since 4.62 it licensed under Public Domain.
So we can use it, if we need.
If you never intend to updat
Oh I know that! I'm just saying that I may try lzma'ing the kernel and
rootfs's to see what kind of savings I get over gzip. :)
Adrian
On 21 February 2010 02:15, Alex RAY wrote:
> Hi,
>
> On Sat, 20 Feb 2010 22:36:02 +0800
> Adrian Chadd wrote:
>
>> On 20 February 2010 04:26, Alex RAY wrote:
Hi,
On Sat, 20 Feb 2010 22:36:02 +0800
Adrian Chadd wrote:
> On 20 February 2010 04:26, Alex RAY wrote:
>
> > :) No, I don`t think about "magically faster", now I near to release
> > FreeBSD firmware for D-Link DIR-320 router which have only 4MB of flash
> > memory. Maybe in next time I try
On 20 February 2010 04:26, Alex RAY wrote:
> :) No, I don`t think about "magically faster", now I near to release FreeBSD
> firmware for D-Link DIR-320 router which have only 4MB of flash memory. Maybe
> in next time I try to make it for some router with only 2MB of flash. In that
> way,
> I n
On Fri, 19 Feb 2010 16:36:40 +0100
Ivan Voras wrote:
> On 02/19/10 15:36, Alexandr Rybalko wrote:
> > Hi,
> > I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma),
> > in connection with this is an issue best left lzma
>
> One of the (relativel
On 02/19/10 15:36, Alexandr Rybalko wrote:
Hi,
I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in
connection with this is an issue best left lzma
One of the (relatively) unexpected problems with such block-level
compression is its efficienty - since you need to
Hi,
I wrote a module GEOM_ULZMA (such as GEOM_UZIP, but compression with lzma), in
connection with this is an issue best left lzma
code in the file "geom_ulzma.c" or store lzma library separately. If
separately, then where better?
Maybe in future make lzma and gzip library kernel int
30 matches
Mail list logo
