On Thu, 2006-03-30 at 12:32, UNIX admin wrote: > I would strongly discourage switching from bzip2. bzip2 may be "slow", but > CPUs will only get faster, and meanwhile, the compression algorithm of bzip2 > will stay the same. > > When one factors in that no other cruncher/compressor/packer/archiver gets > that kind of compressions, I believe that long term gains become pretty > obvious.
Not really. The fastest systems today can't saturate a DVD, 100M network, or hard disk with bzip2. I would happily exchange the 5% loss in compression for the 10x performance win. If you need that 5%, then there are probably other ways to get it back. The ISO images compress (with zip) 20% or so - and that's with the packages bzip2 compressed. > > 3) stop rewriting /var/sadm/install/contents file > > repeatedly. > > Shouldn't that already be eleviated by FS cache in RAM and logging? The cache only works for reads; logging only for metadata. (Casper said it's "transactionally safe". I would think that the relevant transactional unit here is the whole install.) > > If we stored the packages as a single CPIO archive > > instead > > of separate files on the dvd, we could stream the > > data off > > continuously, uncompress it and install it all at the > > same > > time. > > That might work. But what happens when that pesky user selects a custom > installation and thereby screws up the `cpio` package dearchiving order? That's not how I understood it. I thought the idea was that the package would be stored as a single file in datastream format rather than unpacked in filesystem format. Which would cut down a lot of the small I/O operations that are currently necessary. -- -Peter Tribble L.I.S., University of Hertfordshire - http://www.herts.ac.uk/ http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ _______________________________________________ opensolaris-discuss mailing list [email protected]
