On Aug 14, 2009, at 7:15 AM, Alex Lam S.L. wrote:
Thanks for the informative analysis!
Just wondering - are there better candidates out there than even LZO
for this purpose?
tamp is perhaps another interesting candidate. But Tim is in a better
position to say where it is heading.
http://blogs
The only problem I see, is data set size. Let me explain (and please correct
if I'm wrong).
ZFS basically compresses 2 things -- metadata and data. And data is at most
128k chunk.
Each chunk is individually compressed, not the whole file.
This should affect dictionary size for the lzo compre
Just to answer my own question - this one might be interesting:
http://www.quicklz.com/
Alex.
On Fri, Aug 14, 2009 at 3:15 PM, Alex Lam S.L. wrote:
> Thanks for the informative analysis!
>
> Just wondering - are there better candidates out there than even LZO
> for this purpose?
>
> Alex.
>
>
>
Thanks for the informative analysis!
Just wondering - are there better candidates out there than even LZO
for this purpose?
Alex.
On Fri, Aug 14, 2009 at 8:05 AM, Denis Ahrens wrote:
> Hi
>
> Some developers here said a long time ago that someone should show
> the code for LZO compression suppo
On Fri, Aug 14, 2009 at 2:05 PM, Denis Ahrens wrote:
> Some developers here said a long time ago that someone should show
> the code for LZO compression support for ZFS before talking about the
> next step.
Isn't the main problem license, LZO being GPL, while zfs CDDL?
--
Fajar
_
Great read.
On Fri, Aug 14, 2009 at 3:05 AM, Denis Ahrens wrote:
> Hi
>
> Some developers here said a long time ago that someone should show
> the code for LZO compression support for ZFS before talking about the
> next step. I made that code with a friend and we also made a little
> benchmark to
Hi
Some developers here said a long time ago that someone should show
the code for LZO compression support for ZFS before talking about the
next step. I made that code with a friend and we also made a little
benchmark to give a first impression:
http://denisy.dyndns.org/lzo_vs_lzjb/
I hope we ma
