Martin Bochnig wrote: > On Wed, May 27, 2009 at 5:24 PM, Dave Miner <dminer at opensolaris.org> wrote: >> post it to genunix or whereever). A couple of us have in fact tried it, and >> found that there is a bug in lofi (6778233, unfortunately not exported on >> b.o.o) that prevents > 4 GB compressed lofi archives from working correctly, > > > Is this still there? I was in the belief it had been fixed long ago > when clofi went through ARC. Mmmh. Then it is still possible, as you > know, even withouth Juergen Keil's fix. logically splitting zlib > compressed iso archives is inconvenient (if more than just 2 > mountpoints need to be maintained, because first you have to decide > what goes where, then you always have multiple iso's to maintain), but > otherwise works well. Not sure if it is in- or de- creasing I/O > performance to have 2 or more zlib compressed hsfs- archives (other > fs's possible too, but hsfs is preferrable due to Moinak's original > speed improvements, such as read-ahead and sorting the fs-layout) . >
Yes, it's still necessary as that issue wasn't dealt with previously, don't know why since it's a one-liner. I have an image of 2009.06's redistributable package set built with a patched lofi and it works nicely. Yeah, you can split things, but then you run into the problem of updating other parts, such as the SMF start methods, that are aware of the existing structure. There's some architecture work to be done to make this a little more adaptable. > There is or was another clofi bug as well. Not sure if recent versions > still carry it with them: If you clofi-mount a zlib compressed ufs iso > (I got it with ufs, didn't test this with hsfs, not sure if it > matters) that resides within and already mounted other zlib > compressed ufs iso, then the kernel panics instantly when attempting > the 2nd mount. Needs verification if it is still there. > It happened both on SPARC and on x86 (some while ago). > No idea if this is a problem. > >> so you can't do it with the official 2009.06 bits (I'm planning on getting >> Juergen's proposed fix in soon). In terms of what Sun will support in the >> product, it's not likely we'll create lots of variant media for official >> distribution. Adding a repo DVD is planned, but that's the only one on the >> horizon right now. > > > Ok, a Repo-DVD goes much into the right direction. > It sure is better to perform proper IPS installs of most packages > (loop-back IPS in case of the planned Repo-DVD). Applause. Then the > LiveDVD proposal was a bit redundant. Because a LiveDVD always suffers > from the problem of limited I/O throughput, despite all the > improvements (hsfs-read_ahead, compression and therefore reduced I/O > footprint from actual media / rest happens in memory, sorted hsfs > layout). A Dual-Layer LiveDVD using clofi or maybe even Blue-Ray-discs > can carry around huge amounts of LiveMedia-storage (if clofi doesn't > work >= 4GB, then distribute data in enough small <= 4GB compressed > iso's). But the I/O is always a bottleneck. I mean, a Repo-DVD suffers > from the same bottlenecks. But a Repo-DVD does not attempt to start 50 > fat applications concurrently, while reading in all data from the poor > optical storage. A CD is better because due to the limited space on > it, the user has limited choices in terms of how many GUI applications > he can start. Drawback: A CD may be slower in general, than a DVD. > Maybe one could experiment with burning the existing OS2009.06 iso's > contents as a DVD and then take a stop-watch and compare boot time, > and start time of FF. As I understand it a DVD cannot be smaller than > 1GB? Then one needs to add some mkfile created padding before creating > the iso. The results of this experiment might be interesting to see. > Most of the testing I did with live CD's were actually on DVD-RW's; burning less than 1 GB is just fine. Dave
