On Tue, Mar 17, 2009 at 5:39 PM, Dave Miner <Dave.Miner at sun.com> wrote:
> Martin Bochnig wrote:
>
>> This whole thing will simply be a mixture of the MartUX LiveCD/DVD
>> from 2006, crossed with the Natamar test demo LiveCD from September
>> 2008 {#0} divided by Moinaks and Eremins (and others') and your great
>> work.
>>
>> What do you think about it?
>>
>
> I think that we need to work out something that is both performant and
> maintainable. ?The current live CD design meets the former goal reasonably
> well, could be better in terms of maintainability; I'm concerned that your
> outline above seems potentially less maintainable than what we presently
> have. ?Relatedly, a primary goal should be to have x86 and SPARC
> architectures here be common as much as possible, not divergent.
>
> One concern with your suggested approach is whether UFS can sufficiently
> perform for boot time from the media, since we have little or no file system
> layout control with UFS. ?I'm not convinced we need to retain the HSFS
> sorting that we currently do, but it made a difference at one time and needs
> evaluation. ?Something to measure, I think.True, I read about it on Moinak's blog. I don't know if something similar can be achieved on/for UFS, if done manually (like some LinUX LiveCD distributors do with their [hsfs / iso9660 based] media. > > There's also the issue that UFS, by nature of it's smaller block sizes and > thus potentially larger ratio of metadata to data, will likely use more CD > space. ?A 10% increase in overall size (lzma compressed) of the media for > x86 would not be tenable. This is 100% true. Not much used to fit onto the old UFS-root based MartUX LiveCD from 2006, which is the reason why only the DVD was usable at that time. > In any event, memory pressure is a big problem that needs addressing > whatever we do. ?Moinak's cramdisk prototype holds some promise here, but > I've not been able to get it to boot in the limited time I've had to spend > on it. It is the way to go, but needs time and consideration, agreed. Moinak has done amazing work (not only) in that field. > I'd suggest getting started with a child of the slim_source hg repo. ?As > this progresses, we can set up a sub-project repository on the > opensolaris.org infrastructure for coordination until it reaches a point of > integrating into the Caiman project or the consolidations (depending on > timing). Yes, as I said I have checked it out after a few months, so I have the latest bits on my x64 Laptop. Whatever changes we make it is of course clear, that they need to be architecture- and platform clean. So I must admit, that you are right, when it comes to: 1) UFS block size and 2) disk layout performance sorting optimizations Those two things have always been the problem with MartUX 2006 edition (which is the reason why I removed it from the download site). Okay, msg. understood. So keep it as much in sync with x86, as somehow possible. But how do you think about splitting sun4u and sun4v kernels into separate mini (or micro-) roots? Either in a per iso fashion, or with the need to specify the desired miniroot on the OBP command line? This significantly reduces the archive's size. And when done in addition to dcfs, Moinak's solution or what Eremin has done, it will reduce boot time (reading the archive into memory and different ways of uncompressing) and physical mem-requirements to an acceptable level. What is your opinion about it? -- %martin
