I broke lrzuntar in version 0.605 when I disabled automatic stdout on lrzip so this is a tiny bugfix release to make lrzuntar work again.
lrzip on freshmeat
Saturday, 14 May 2011
Wednesday, 11 May 2011
BFS 0.402 test2 for 2.6.39-rc7
Well it looks like another stable release is just around the corner, so it's time for me to sync up. Here's the first BFS test release patch for 2.6.39-rc7:
2.6.39-rc7-sched-bfs-402-test2.patch.lrz
Of course I've used my evil powers to compress it with lrzip as a ploy to make you all have to use it again.
I've been using it for a few hours and it seems to be stable enough, but all the usual warnings apply. I also tested it on the most common configurations, but that doesn't mean it will definitely build fine on all configurations.
The only changes in the impending final release of BFS version 0.402 include some changes inspired by the people posting changes here in the forums (Thanks guys!), though not exactly in the form offered, and a resync of the new changes required to support 2.6.39. Specifically there is more high resolution IRQ accounting, and a new syscall "yield_to".
Funnily enough, it was a good 6 years or so ago I had a discussion with William Lee Irwin III who suggested such a yield call as a useful programming addition which of course was discounted by the mainline maintainers back then. Now they suddenly find it's a useful idea after all, since there may well be scenarios where a directed yield is helpful instead of strict locking semantics. Oh well, I guess there is the adage that you should only ever implement a feature at the time you need it rather than "for when you might need it in the future". The difference now from back then is that the people who wanted it back then couldn't push so hard since they weren't kernel hackers themselves. This time it's KVM that desires it, so it's required by another part of the kernel instead of userspace.
So anyway, please test and report back, and enjoy!
2.6.39-rc7-sched-bfs-402-test2.patch.lrz
Of course I've used my evil powers to compress it with lrzip as a ploy to make you all have to use it again.
I've been using it for a few hours and it seems to be stable enough, but all the usual warnings apply. I also tested it on the most common configurations, but that doesn't mean it will definitely build fine on all configurations.
The only changes in the impending final release of BFS version 0.402 include some changes inspired by the people posting changes here in the forums (Thanks guys!), though not exactly in the form offered, and a resync of the new changes required to support 2.6.39. Specifically there is more high resolution IRQ accounting, and a new syscall "yield_to".
Funnily enough, it was a good 6 years or so ago I had a discussion with William Lee Irwin III who suggested such a yield call as a useful programming addition which of course was discounted by the mainline maintainers back then. Now they suddenly find it's a useful idea after all, since there may well be scenarios where a directed yield is helpful instead of strict locking semantics. Oh well, I guess there is the adage that you should only ever implement a feature at the time you need it rather than "for when you might need it in the future". The difference now from back then is that the people who wanted it back then couldn't push so hard since they weren't kernel hackers themselves. This time it's KVM that desires it, so it's required by another part of the kernel instead of userspace.
So anyway, please test and report back, and enjoy!
Sunday, 8 May 2011
lrzip-0.605
A few minor bugs have shown up since version 0.604 that people have spotted, so I've attended to them and added a new lrzcat symbolic link and released version 0.605. Here's the changelog:
Addition of lrzcat - automatically decompresses .lrz files to STDOUT. lrzip and lrunzip will no longer automatically output to STDOUT when output is redirected. Progress output will no longer spam the output unless the percentage has changed. lrzip now has no lower limit on file sizes it will happily compress and is able to work with zero byte sized files. The percentage counter when getting file info on small files will not show %nan. The executable bit will not be enabled when compressing via a means that can't preserve the original permissions (e.g. from STDIN).
I'm now getting reports that lrzip is sneaking into many distribution repositories, that the 'file' command is finally getting support for .lrz files, and that rpm is even including support for lrzip compressed files. Great news, and thanks to the packagers and other developers.
Get version 0.605 from here: LRZIP 0.605 on freshmeat
Happy Mother's day if you're celebrating it in your part of the world.
Addition of lrzcat - automatically decompresses .lrz files to STDOUT. lrzip and lrunzip will no longer automatically output to STDOUT when output is redirected. Progress output will no longer spam the output unless the percentage has changed. lrzip now has no lower limit on file sizes it will happily compress and is able to work with zero byte sized files. The percentage counter when getting file info on small files will not show %nan. The executable bit will not be enabled when compressing via a means that can't preserve the original permissions (e.g. from STDIN).
I'm now getting reports that lrzip is sneaking into many distribution repositories, that the 'file' command is finally getting support for .lrz files, and that rpm is even including support for lrzip compressed files. Great news, and thanks to the packagers and other developers.
Get version 0.605 from here: LRZIP 0.605 on freshmeat
Happy Mother's day if you're celebrating it in your part of the world.
Wednesday, 27 April 2011
lrzip-0.604
A one bug fix release.
Changelog:
Detach threads after creating them on the compression side. Not joining them meant that compressing massive files requiring hundreds of threads would eventually hit the resource limit of number of threads created even though the threads themselves would exit.
English:
lrzip will no longer fail with a "resource temporarily unavailable" error when compressing files over 100GB that require hundreds of threads to complete.
Get it here: LRZIP
Changelog:
Detach threads after creating them on the compression side. Not joining them meant that compressing massive files requiring hundreds of threads would eventually hit the resource limit of number of threads created even though the threads themselves would exit.
English:
lrzip will no longer fail with a "resource temporarily unavailable" error when compressing files over 100GB that require hundreds of threads to complete.
Get it here: LRZIP
Subscribe to:
Posts (Atom)