Martin Bochnig wrote:
> On Tue, Mar 17, 2009 at 9:18 AM, sanjay nadkarni (Laptop)
> <Sanjay.Nadkarni at sun.com> wrote:
>> Martin Bochnig wrote:
>>> Hello all :)
>>>
>>> Sorry, I was not subscribed to this list for over a year.
>>> I am familiar with the repos, but didn't read any meeting minutes or
>>> the huge mail archives.
>>>
>>> Can somebody please clarify what has been the reason to not produce
>>> any bootable LiveCD for SPARC, but to go the AI way exclusively?
>>>
>> Given the limited resources, we needed to decide what to tackle first for
>> Sparc.
>> We noticed that the set of graphics drivers for sparc was limited. Sparc
>> systems were mostly
>> servers and jumpstart was the most common way to install them. Therefor we
>> decided
>> to tackle AI *first*.
>
>
> Hi Sanjay,
>
> thanks for the quick response.
> Okay, so it sounds as if a LiveCD is still on the table? That's great.
> I think Sun and I, and me and Sun have made peace now. So this means
> that I can simply interact with you engineers via lists like
> caiman-discuss.
>
> Here is my simple idea for SPARC-LiveCD: Use UFS (with nologging) at
> the lowest layer of the CD, similar to the old install CD's.
> Effectively emulate a read-only hdd with one or more read-only UFS
> slice(s), maybe tweak UFS read-ahead performance by means of Moinak's
> latest work. This allows us to keep most things on the CD's root,
> rather than in any bootarchive.
> The entry in /etc/system for keeping the ramdisk as "/"-fs will be
> disabled. So the ramdisk gets discarded and the "/"-fs will reside on
> the CD-root, just like during a normal newboot hdd-boot (of an
> installed system)
> All additional files (everything not required for the boot) get into
> compressed hsfs or maybe even ufs archives (if this brings any benefit
> beyond the easier re-creation options, by having rw-access to such an
> archive, which is never the case if you want to modify a hsfs based
> archive [e.g. If a distro developer needs to change only one file, for
> hsfs she has to recreate the entire archive. In case of UFS you can
> simply mount it, make a change, done.]) and get c-lofi mounted. All
> parts which need to be rw reside in tmpfs and get lofs-mounted over ro
> mountpoints inside the ro-UFS-CD-root (or in some cases simply
> symlinked to /tmp/foo/sub-foo) to the mountpoints which need write
> access, such as parts of /var.
>
> 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.
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.
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 relatively easy and - if desired - can be done relatively quickly.
>
> {#0}
> http://martux.org/SPARC_distro_incl_Xorg7.2/cdrom__NoGnome_NoJDS_with_icewm/
>
> Be aware that www.natamar.org is in my possession and online (although empty).
> If the first phase does not pass Sun's challenging quality standards,
> we could simply put it onto my site, under the MartUX brand, where you
> have no responsibility and nobody can request support from you.
> Then - if it gets more complete and stable - you can take it from your
> gate (I would need rw access, maybe) and adjust everything to your
> needs.
>
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).
Dave
