Martin Bochnig wrote:
> 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.
>
Seems unlikely to me. If we were going to do it anywhere, it would
probably make more sense to do it in ZFS and use that instead.
>
>> 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.
>
Maybe that's something you can spend some time looking into? I've only
managed an hour here and there and haven't made much progress.
>> 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?
>
I wouldn't be opposed to splitting them, and indeed I'm having to
consider something like this for x86 as well (64- vs. 32-bit) to get 512
MB installs working again. I'd much rather not have to specify it on
the command line, though. Usability drops greatly when you have to know
what flavor of SPARC you have in order to even try to boot it.
> 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?
>
I'm in favor of faster booting and lower memory usage ;-)
Dave
