On Sat, 3 Nov 2001, Karl J. Runge wrote: > Why don't you guys try bzip2(1).
In my experience, bzip2 is *much* slower than gzip. In a test against a 16 MB segment of the kernel source tarchive, it yielded a compressed output 19% smaller than gzip, but took 73% more CPU time. In cases that are pathologically bad for bzip2 (lots of repeated bytes), the difference is more like 10,000% times slower. No, that is not a typo -- one hundred times slower. Now, granted, with today's CPU speeds, one may have the performance to spare, but I am still worried about the tape drive stalling. > The b stands for "block compression" It stands for "block-sorting", actually. :-) > bzip2recover evidently aids in this. From what I understand, bzip2recover simply reads the input, looks for block boundaries, and creates output files for each recognizable block. I suspect that would not work well on a 300 gigabyte tape set. :-) -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
