Trying to polish off version 0.6x of lrzip to be nice and stable and working as planned, I've made a few more updates addressing a few issues that have come up, along with some outside help. Here's the short changelog:
lrzip now detects when output is being redirected without a filename and will automatically output to stdout. Apple builds, which had errors on compressing files larger than 2GB in size, were fixed. lrztar now properly supports -o, -O, and -S. The lrzip configuration file now supports encryption. lrzip will now warn if it's inappropriately passed a directory as an argument directly.
Probably the most fun part of this is the first feature upgrade to do with stdout, which I use regularly now since I store all my kernels and patches as .lrz, I can now do:
lrunzip patch-184.108.40.206.lrz | patch -p1
Also, graysky made some nice graphs and I feel obliged to put them up here:
Of course, with much larger files and more CPUs and RAM the discrepancy becomes much greater with lrzip but that doesn't change the fact this is a real world test.
So grab it here:
LRZIP ON FRESHMEAT
As an aside, debian unstable now has 0.602+ in its repo, and the upcoming elite release of slackware also has 0.602.
v0.603 rocks! You might wanna add the following info for context around the benchmark I ran:ReplyDelete
Experiment is compressing the kernel-2.6.38 source (393 MB) to four formats:
lrztar --> .lrz
tar -zcf --> .gz
tar -jcf -->.bz2
tar -Jcf --> .xz
I ran each compression 40 times via a script @ ondemand, then each compression an additional 40 times @ performance. (Love bash scripts)!
-X3360 (Xeon version of Q9550 so quad core) @ 3.40 GHz (8 G RAM)
-Kernel 220.127.116.11 + CK3 patchset on Arch Linux x86_64
-Ran in runmode 3 with minimal daemons
-Ran in /dev/shm (ramfs) so no access time issues
@ As an aside, debian unstable now has 0.602+ in its repoReplyDelete
Awesome I am going to install this.