Bruno Wolff III wrote: > On Wed, Mar 10, 2010 at 16:06:35 +0100, > Roberto Ragusa <mail@xxxxxxxxxxxxxxxx> wrote: >> Bruno Wolff III wrote: >>> I did test an lzma compressed live image (non-functional due to no kernel >>> support) for the games spin and found it was 10% (400 MiB) smaller than >>> the zlib compressed version. >> Isn't the basic strength of lzma a very big dictionary window? >> I would have said this is not easily paired to random access (squashfs). >> 10% (of the compressed size) looks like a very good gain. > > I haven't done performance testing on live images. It is claimed that lzma > decompresses at good speeds compared to other options. > My expectation is reduced accesses to slow media (especially CDs and DVDs) > will outweigh other effects. > I have been holding off on testing things that need kernel support. If Kyle > lets me get squashfs 4.1 in rawhide or F13 and Lougher posts a revised > set of patches that will work with his clean up patches that have already > been pulled, then I'll look at doing some testing of live images and mounted > file systems. I wasn't planning on detailed benchmarks for that, just seeing > if things obviously sucked compared to zlib. Wow, this could get complex fast! Let me start by saying I am not disagreeing with you. That said, I have noticed that install off USB thumb drive is faster than DVD by a good bit, even though the transfer rate off a DVD is almost certainly faster. This suggests that seek is the limiting factor delay rather than transfer rate. Therefore you comment about seek and squashfs is interesting, and open the question of whether it would be better to use an uncompressed ISO filesystem and better compression on the RPMs. I wouldn't guess without testing. I share the impression that a huge window is the cause of both better better and slower compression. -- Bill Davidsen <davidsen@xxxxxxx> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
