Hi, I don''t know if this has been discussed before, but have you thought about adding LZO compression to ZFS? One zfs-fuse user has provided a patch which implements LZO compression, and he claims better compression ratios *and* better speed than lzjb. The miniLZO library is licensed under the GPL, but the author specifically says that other licenses are available by request. Has this been considered before?
zfs-discuss-bounces at opensolaris.org wrote on 04/18/2007 10:30:41 AM:> Hi, > > I don''t know if this has been discussed before, but have you thought > about adding LZO compression to ZFS? > > One zfs-fuse user has provided a patch which implements LZO compression, > and he claims better compression ratios *and* better speed than lzjb. > > The miniLZO library is licensed under the GPL, but the author > specifically says that other licenses are available by request. > > Has this been considered before? >FUSE can do this because it runs mostly in user space, Solaris zfs compression needs to be called in kernel -- so far lzjb and gzip kernel implementations have been found and utilized for Solaris ZFS.
Ricardo Correia wrote:> Hi, > > I don''t know if this has been discussed before, but have you thought > about adding LZO compression to ZFS? > > One zfs-fuse user has provided a patch which implements LZO compression, > and he claims better compression ratios *and* better speed than lzjb. > > The miniLZO library is licensed under the GPL, but the author > specifically says that other licenses are available by request.A CDDL compatible license for miniLZO would be needed for this to be acceptable in OpenSolaris. I''d also highly recommend checking that this actually works for ZFS in the kernel - which also means porting miniLZO to be a kernel module on Solaris. -- Darren J Moffat
Darren J Moffat wrote:> > I''d also highly recommend checking that this actually works for ZFS in > the kernel - which also means porting miniLZO to be a kernel module on > Solaris.I don''t see why it shouldn''t. From the LZO homepage: # Decompression is simple and */very/* fast. # Requires no memory for decompression. # Compression is pretty fast. # Requires 64 kB of memory for compression. # There is also a compression level which needs only 8 kB for compression. # Algorithm is thread safe.
Ricardo Correia wrote:> Darren J Moffat wrote: >> I''d also highly recommend checking that this actually works for ZFS in >> the kernel - which also means porting miniLZO to be a kernel module on >> Solaris. > > I don''t see why it shouldn''t. From the LZO homepage: > > # Decompression is simple and */very/* fast. > # Requires no memory for decompression. > # Compression is pretty fast. > # Requires 64 kB of memory for compression. > # There is also a compression level which needs only 8 kB for compression. > # Algorithm is thread safe.Until someone tries though you really never know what needs to be done. I would highly recommend getting LZO up and running as a Solaris kernel module - it might not be trivial or you could be lucky and it will "just work" . Writing a library and writing a kernel module have important and significant differences. -- Darren J Moffat
Darren J Moffat wrote:> Until someone tries though you really never know what needs to be done. > I would highly recommend getting LZO up and running as a Solaris > kernel module - it might not be trivial or you could be lucky and it > will "just work" . Writing a library and writing a kernel module have > important and significant differences.Ok, I understand. I don''t have any plans to do this though, I was just proposing the idea. Besides, there''s still the licensing issue.
For what it''s worth, at a previous job I actually ported LZO to an OpenFirmware implementation. It''s very small, doesn''t rely on the standard libraries, and would be trivial to get running in a kernel. (Licensing might be an issue, of course.) This message posted from opensolaris.org
On Wed, Apr 18, 2007 at 06:58:46PM -0700, Anton B. Rang wrote:> For what it''s worth, at a previous job I actually ported LZO to an OpenFirmware implementation. It''s very small, doesn''t rely on the standard libraries, and would be trivial to get running in a kernel. (Licensing might be an issue, of course.)Licensing? But SUN can just relicense ZFS to GPL, can''t it? :) /me runs -- Pawel Jakub Dawidek http://www.wheel.pl pjd at FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070419/3d2be8b9/attachment.bin>
Forwarding some simple benchmarks, just to peek your curiosity.
Very interesting results.
-------- Original Message --------
Subject: [zfs-fuse] probably some better numbers ;)
Date: Thu, 19 Apr 2007 22:07:31 +0200
From: roland <devzero at web.de>
Reply-To: zfs-fuse at googlegroups.com
To: <zfs-fuse at googlegroups.com>
References: <5db666110704190305j2c6061d2ya41fce0d7770990a at
mail.gmail.com>
linux kernel source, (239M)
time tar xf linux-2.6.20.3.tar
|compression |time-real |time-user |time-sys |compressratio
--------------------------------------------------------------
|lzo |6m39.603s |0m1.288s |0m6.055s |2.99x
|gzip |7m46.875s |0m1.275s |0m6.312s |3.41x
|lzjb |7m7.600s |0m1.227s |0m6.033s |1.79x
|off |7m26.735s |0m1.348s |0m6.230s |1.00x
this test was done an an ancient suse 9.1 box, fuse 2.5.3, 1,25 GB RAM
(1 gb
in use for other apps), 2x80gb 3ware raid1
first (vague) conclusion:
gzip compresses best, lzo is fastest and it seems that fuse (or
whatever) is
the real bottleneck - at least not cpu or i/o
after waiting for so long - 2 additional compression schemes for zfs - in
one day!
thanks ricardo and thanks eric for making this !
so, now someone willing to implement bzip2 compression ?
:D
regards
roland
ps:
maybe someone likes to test this on a newer system? i have no suiteable
around here for now - maybe later.....
----- Original Message -----
From: Eric Dillmann
To: zfs-fuse
Sent: Thursday, April 19, 2007 12:05 PM
Subject: [zfs-fuse] Some numbers
tar cf - zfs-fuse | (cd /wd1/test-lzo/;time tar xf -)
0.07user 0.32system 0:07.97elapsed 4%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+306minor)pagefaults 0swaps
tar cf - zfs-fuse | (cd /wd1/test-lzjb/;time tar xf -)
0.08user 0.45system 0:09.97elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+306minor)pagefaults 0swaps
tar cf - zfs-fuse | (cd /wd1/test-gzip/;time tar xf -)
0.08user 0.41system 0:13.80elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+305minor)pagefaults 0swaps
zfs get compressratio
wd1/test-gzip compressratio
-
wd1/test-lzo compressratio
-
wd1/test-lzjb compressratio
-
Regards,
Eric
Ricardo Correia wrote:> |compression |time-real |time-user |time-sys |compressratio > -------------------------------------------------------------- > |lzo |6m39.603s |0m1.288s |0m6.055s |2.99x > |gzip |7m46.875s |0m1.275s |0m6.312s |3.41x > |lzjb |7m7.600s |0m1.227s |0m6.033s |1.79x > |off |7m26.735s |0m1.348s |0m6.230s |1.00xBTW, those time-sys numbers do not have any real meaning since in zfs-fuse the ZFS code runs under the context of another process.
please be cautious with this benchmarks and don`t make early decisions based on this. This message posted from opensolaris.org
>For what it''s worth, at a previous job I actually ported LZO to an OpenFirmware >implementation. It''s very small, doesn''t rely on the standard libraries, and would be >trivial to get running in a kernel. (Licensing might be an issue, of course.)just for my personal interest - are you speaking of a kernel port? linux, solaris or what OS ? could you tell which firmware ? actually, in-kernel lzo compression for linux has just been implemented and being discussed on lkml. ( see http://marc.info/?l=linux-kernel&w=2&r=1&s=lzo&q=b) This message posted from opensolaris.org
btw - is there some way to directly compare lzjb vs lzo compression - to see which performs better and using less cpu ? here those numbers from my little benchmark: |lzo |6m39.603s |2.99x |gzip |7m46.875s |3.41x |lzjb |7m7.600s |1.79x i`m just curious about these numbers - with lzo i got better speed and better compression in comparison to lzjb nothing against lzjb compression - it''s pretty nice - but why not taking a closer look here? maybe here is some room for improvement.... roland This message posted from opensolaris.org
Hi roland, roland <devzero at web.de> wrote:> btw - is there some way to directly compare lzjb vs lzo compression - > to see which performs better and using less cpu ? > > here those numbers from my little benchmark: > > |lzo |6m39.603s |2.99x > |gzip |7m46.875s |3.41x > |lzjb |7m7.600s |1.79xand how small was the files after compressing? Greetings Cyron -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070617/a80059b5/attachment.bin>
last number (2.99x) is compression ratio and was much better than lzjb. not sure if there is some mistake here, i was quite surprised that it was so much better than lzjb.... This message posted from opensolaris.org
Those are interesting results. Does this mean you''ve already written lzo support into ZFS? If not, that would be a great next step -- licensing issues can be sorted out later... Adam On Sat, Jun 16, 2007 at 04:40:48AM -0700, roland wrote:> btw - is there some way to directly compare lzjb vs lzo compression - to see which performs better and using less cpu ? > > here those numbers from my little benchmark: > > |lzo |6m39.603s |2.99x > |gzip |7m46.875s |3.41x > |lzjb |7m7.600s |1.79x > > i`m just curious about these numbers - with lzo i got better speed and better compression in comparison to lzjb > > nothing against lzjb compression - it''s pretty nice - but why not taking a closer look here? maybe here is some room for improvement.... > > roland > > > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
>Those are interesting results.yes, indeed>Does this mean you''ve already written lzo support into ZFS?no, i`m not a "real" coder, but there exists an lzo patch for zfs-fuse which has also been discussed here, afaik. not sure if this has already been included in zfs-fuse tree - just wanted to check out, but website (http://www.wizy.org/wiki/ZFS_on_FUSE) seems down for the moment - if this takes longer to recover (happens often and normally doesn`t) maybe i have it left on my system somewhere where i tried zfs-fuse with lzo patch and where i did thos performance comparison. also see: http://groups.google.com/group/zfs-fuse/tree/browse_frm/month/2007-04/541ff514ecc880b2?rnum=31&_done=%2Fgroup%2Fzfs-fuse%2Fbrowse_frm%2Fmonth%2F2007-04%3F#doc_a489f630aa4aa189 http://groups.google.com/group/zfs-fuse/tree/browse_frm/month/2007-04/b85b3bd20725fec6?rnum=11&_done=%2Fgroup%2Fzfs-fuse%2Fbrowse_frm%2Fmonth%2F2007-04%3F#doc_b85b3bd20725fec6>If not, that would be a great next stepif other performance comparisons give similar results, i really think so. not sure, if my results are reliable, but at least it`s worth taking a closer look, because also eric dillman told, it would perform better than lzjb - at least with zfs-fuse.>licensing issues can be sorted out later..good attitude ! :) zfs-fuse author/maintainer is Ricardo Correia and the lzo patch was done by Eric Dillmann. I can provide contact data if you like. roland This message posted from opensolaris.org
This LZO issue is something that might crop up again and again in different shapes. If ZFS is being adopted on different operating systems, people might start cooking their own soups. What are the plans to keep this under control? What if Unix Variant/Clone X suddenly decides their ZFS code needs to support three new compression schemes as well two new hashes? Disregarding that there doesn''t seem to be much merit to that (though LZO seems promising), this could hinder interoperability. Now lets consider a worse case, what if Unix Variant Y thinks it figured out some nice performance tweaks, but requires changes to the on-disk layout? I''m just saying this, because OpenSolaris is the smaller player at the table. Going with the hypothetical scenario where OpenSolaris goes GPLv3 and Linux merging ZFS into the kernel, they could just bully in changes. Maybe I''m just being paranoid, but the point still stands. The filesystem isn''t that widely established, so one could be tempted to break things. -mg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 648 bytes Desc: This is a digitally signed message part URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070618/2362b7f4/attachment.bin>
On 6/18/07, Mario Goebbels <me at tomservo.cc> wrote:> Now lets consider a worse case, what if > Unix Variant Y thinks it figured out some nice performance tweaks, but > requires changes to the on-disk layout?Perhaps a variant on Knuth''s TeX license could be used? "You can do what you like with it, but if you don''t put your additional code under this license, you can''t call it ZFS." Will
Mario Goebbels wrote:> This LZO issue is something that might crop up again and again in > different shapes. If ZFS is being adopted on different operating > systems, people might start cooking their own soups.I don''t know about any legal restrictions that might or might not be in place to prevent or allow that. Speak to your lawyer. But, as a leader of Sun''s ZFS team, and the OpenSolaris ZFS community, I would do everything in my power to prevent the ZFS on-disk format from diverging in different implementations. Let''s discuss the issues on this mailing list as they come up, and try to arrive at a conclusion which offers the best ZFS for *all* ZFS users, OpenSolaris or otherwise. In this particular issue, I agree with Adam -- let''s see the LZO/ZFS code and go from there. FYI, we''re already working with engineers on some other ports to ensure on-disk compatability. Those changes are going smoothly. So please, contact us if you want to make (or want us to make) on-disk changes to ZFS for your port or distro. We aren''t that difficult to work with :-) --mat
some other funny benchmark numbers: i wondered how performance/compressratio of lzjb,lzo and gzip would compare if we have optimal compressible datastream. since zfs handles repeating zero`s quite efficiently (i.e. allocating no space) i tried writing non-zero values. the result is quite interesting, so i`m posting it here. writing a 200meg file ( time dd if=/dev/zero bs=1024k count=200 |tr ''\0'' ''a'' >test.dat ) has the following results (compression used |time needed |compressratio) lzo | 0m10.872s | 118.32x <- (!) lzjb | 0m11.886s | 27.94x gzip | 0m17.418s | 219.64x regards roland This message posted from opensolaris.org
On 6/30/07, roland <devzero at web.de> wrote:> some other funny benchmark numbers: > > i wondered how performance/compressratio of lzjb,lzo and gzip would compare if we have optimal compressible datastream. > > since zfs handles repeating zero`s quite efficiently (i.e. allocating no space) i tried writing non-zero values. > > the result is quite interesting, so i`m posting it here. > > writing a 200meg file ( time dd if=/dev/zero bs=1024k count=200 |tr ''\0'' ''a'' >test.dat ) has the following results (compression used |time needed |compressratio) > > lzo | 0m10.872s | 118.32x <- (!) > lzjb | 0m11.886s | 27.94x > gzip | 0m17.418s | 219.64x >Roland, which platform are you running these bits on ? Solaris or Linux ? -- Regards, Cyril
this is on linux with zfs-fuse (since no other zfs implementation besides zfs-fuse has support for lzo at this time) btw - here is some additional comparison - now with some real-world data. copying over some mysql database dir (var/lib/mysql) of size 231M gives: lzo | 0m41.152s | 2.31x lzjb | 0m42.976s | 1.83x gzip |1m21.637s | 3.26x i cannot tell if lzo and lzjb performance is really comparable, since zfs-fuse/linux may behave very differently to zfs/solaris - but in comparison with lzjb, lzo compression seems to give better results overall. btw: besides opensource lzo there is some closed source lzo professional which is even more optimzied. maybe sun should think about lzo in zfs - albeit those licensing issues. i`m sure that could be resolved somehow, maybe by spending an appropriate amount of bucks to mr. oberhumer. roland This message posted from opensolaris.org
Hello Matthew,
Monday, June 18, 2007, 7:28:35 PM, you wrote:
MA> FYI, we''re already working with engineers on some other ports to
ensure
MA> on-disk compatability. Those changes are going smoothly. So please,
MA> contact us if you want to make (or want us to make) on-disk changes to
ZFS
MA> for your port or distro. We aren''t that difficult to work with
:-)
If it''s not secret - can you say what ports are you talking about?
--
Best regards,
Robert mailto:rmilkowski at task.gda.pl
http://milek.blogspot.com
Robert Milkowski wrote:> Hello Matthew, > > Monday, June 18, 2007, 7:28:35 PM, you wrote: > > MA> FYI, we''re already working with engineers on some other ports to ensure > MA> on-disk compatability. Those changes are going smoothly. So please, > MA> contact us if you want to make (or want us to make) on-disk changes to ZFS > MA> for your port or distro. We aren''t that difficult to work with :-) > > If it''s not secret - can you say what ports are you talking about?Primarily the MacOS X port. --matt
Hello Matthew, Thursday, July 26, 2007, 2:56:32 PM, you wrote: MA> Robert Milkowski wrote:>> Hello Matthew, >> >> Monday, June 18, 2007, 7:28:35 PM, you wrote: >> >> MA> FYI, we''re already working with engineers on some other ports to ensure >> MA> on-disk compatability. Those changes are going smoothly. So please, >> MA> contact us if you want to make (or want us to make) on-disk changes to ZFS >> MA> for your port or distro. We aren''t that difficult to work with :-) >> >> If it''s not secret - can you say what ports are you talking about?MA> Primarily the MacOS X port. Thank you. ps. so not windows port? :))) or maybe windows is secondary one :))))) -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
On 26-Jul-07, at 1:24 PM, Robert Milkowski wrote:> Hello Matthew, > > Thursday, July 26, 2007, 2:56:32 PM, you wrote: > > MA> Robert Milkowski wrote: >>> Hello Matthew, >>> >>> Monday, June 18, 2007, 7:28:35 PM, you wrote: >>> >>> MA> FYI, we''re already working with engineers on some other ports >>> to ensure >>> MA> on-disk compatability. Those changes are going smoothly. So >>> please, >>> MA> contact us if you want to make (or want us to make) on-disk >>> changes to ZFS >>> MA> for your port or distro. We aren''t that difficult to work >>> with :-) >>> >>> If it''s not secret - can you say what ports are you talking about? > > MA> Primarily the MacOS X port. > > Thank you. > > ps. so not windows port? :))) or maybe windows is secondary one :)))))You like Windows /that much/ ? Note Sun isn''t doing the OS X port, Apple is. --T> > > -- > Best regards, > Robert mailto:rmilkowski at task.gda.pl > http://milek.blogspot.com > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Hello Toby, Thursday, July 26, 2007, 6:18:46 PM, you wrote: TT> On 26-Jul-07, at 1:24 PM, Robert Milkowski wrote:>> Hello Matthew, >> >> Thursday, July 26, 2007, 2:56:32 PM, you wrote: >> >> MA> Robert Milkowski wrote: >>>> Hello Matthew, >>>> >>>> Monday, June 18, 2007, 7:28:35 PM, you wrote: >>>> >>>> MA> FYI, we''re already working with engineers on some other ports >>>> to ensure >>>> MA> on-disk compatability. Those changes are going smoothly. So >>>> please, >>>> MA> contact us if you want to make (or want us to make) on-disk >>>> changes to ZFS >>>> MA> for your port or distro. We aren''t that difficult to work >>>> with :-) >>>> >>>> If it''s not secret - can you say what ports are you talking about? >> >> MA> Primarily the MacOS X port. >> >> Thank you. >> >> ps. so not windows port? :))) or maybe windows is secondary one :)))))TT> You like Windows /that much/ ? Note Sun isn''t doing the OS X port, TT> Apple is. It has nothing to do if I like it or not. It''s the question if ZFS could become default file system on most important platform. -- Best regards, Robert mailto:rmilkowski at task.gda.pl http://milek.blogspot.com
Accessibility of the data is also a reason, in dual boot scenarios. Doesn''t need to be a native Windows driver, but something that still ties into the Explorer. There''s still the option of running Solaris in VMware, but that''s a bit heavy handed. -mg> TT> You like Windows /that much/ ? Note Sun isn''t doing the OS X port, > TT> Apple is. > > It has nothing to do if I like it or not. > It''s the question if ZFS could become default file system on most > important platform. > >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 648 bytes Desc: OpenPGP digital signature URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20070727/b1cbad7d/attachment.bin>
Windows has a "user mode driver frame work" thingy - came across it recently in the lsit of services on my XP box. Perhaps this could be used to host a ZFS driver on Windows? Andrew. This message posted from opensolaris.org
nothing new on this? i''m really wondering that interest in alternative compression schemes is that low, especially due to the fact that lzo seems to compress better and be faster than lzjb. nobody at sun who has done further investigation ? This message posted from opensolaris.org
On Sat, 12 Apr 2008, roland wrote:> > i''m really wondering that interest in alternative compression > schemes is that low, especially due to the fact that lzo seems to > compress better and be faster than lzjb.LZO seems to have a whole family of compressors. One reason why it is faster is that the author has worked really hard on a few CPU-specific optimizations. Is the license ok for Solaris? Bob =====================================Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
On Sat, Apr 12, 2008 at 4:58 PM, Bob Friesenhahn < bfriesen at simple.dallas.tx.us> wrote:> On Sat, 12 Apr 2008, roland wrote: > > > > i''m really wondering that interest in alternative compression > > schemes is that low, especially due to the fact that lzo seems to > > compress better and be faster than lzjb. > > LZO seems to have a whole family of compressors. One reason why it is > faster is that the author has worked really hard on a few CPU-specific > optimizations. Is the license ok for Solaris? > > Bob > =====================================> Bob Friesenhahn > bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ > GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ > > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discussDistributed under the terms of the GNU General Public License<http://www.oberhumer.com/opensource/gpl.html>(GPL). Commercial licenses are available on request. I''m sure he would be willing to work something out with Sun to get it licensed under CDDL. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20080412/40f6d8b3/attachment.html>
roland wrote:> nothing new on this? > > i''m really wondering that interest in alternative compression schemes is that low, especially due to the fact that lzo seems to compress better and be faster than lzjb. > > nobody at sun who has done further investigation ? >I''m not aware of anyone at Sun doing further investigation on new compressors for ZFS. However, there is some interesting work being done on parallelized bzip2. Now that we have low-cost machines with 128 threads, parallel codes are getting a lot of attention :-) -- richard