[indiana-discuss] 3.1) Installation

[Moinak Ghosh]

Glynn Foster wrote:
> Hey,
>
> Given that we now have a relatively solid base to start discussion, I figured it
> would be good to focus in on some of these points, ironing out specific detail,
> and technical implementation of what is and isn't possible right now.
>
> This is just a first mail to kick off the discussion at a somewhat higher level
> than I'd like, but it would be good to hear from the folks closer to the ground
> on this one - there's obviously missing issues that we need to discuss, and I'm
> anxious to get those surfaced as soon as possible.
>
> Glynn Foster wrote:
>   
>>         INS-1: Provide infrastructure to install Indiana from
>>                a single CD. The default install should be a
>>                graphical experience, with a text console install
>>                if preferred. The core install will be a basic
>>                operating system and desktop environment.
>>     
>
>
> Install
> =======
> The Caiman guys are currently working on a small subset of their original
> architecture which looks like it may well suit initial needs.
>
>   Currently targeting x86 only, and doesn't look like SPARC boot support
>   is written. I have no idea on the scope of the work needed to provide
>   this, but obviously has direct impact on the concern that Alan brought
>   up
>   

   MartUX should be of interest here.

> [...]
>   A LiveCD 'try first, install later' isn't currently on the feature list
>   for dwarf, so another question is whether we need to punt this until
>   the install guys have had a chance to work on the rest of their
>   infrastructure. Is there anything that we can benefit from the LiveMedia
>   or BeleniX projects? As John already commented, is mixing the LiveCD
>   functionality with the core install CD a requirement? Perhaps not.
>   

   Just a few days back Dave Miner has commited a minimal installer to 
the LiveMedia
   repository possibly derived off the Caiman work. BeleniX also bundles 
a basic installer
   written using Perl-Curses. Some of that logic including auto-layout 
logic will prove
   useful.

>   [insert missing detail]
>
>
> Media Contents
> ==============
> If we limit it to a single CD install, it puts off a lot of questions about what
> to include in terms of media contents.
>
>   We need to get a rough idea of file sizes for the various
>   consolidations as they currently stand. Assuming it should easily
>   be possible to do a core kernel install, basic utilities and a desktop
>   environment how much space does that currently consume?
>
>   Will adding compression support give us more space? If we have
>   more space to play with, do we provide more choice to our
>   users? Does this have an impact on the install experience from
>   a speed point of view that our users aren't willing to compromise
>   over? Will ordering the bits on the media better bring us above
>   that acceptable threshold?
> 	
>   

   Disk data compression has benefits and drawbacks. It depends on 
various factors whether
   benefits will outweigh drawbacks:

   Drawbacks:  Increased processing required to decompress on the fly. 
This can add CPU
   overhead and delay.

   Benefits:  Transferring compressed pages to and from disk reduces I/O 
requirements. More
   data can be transferred per I/O. Compressing data on disk packs bits 
physically closer on
   the media reducing disk head movement beneficial for devices where 
seek time is important.
   Caching compressed pages requires less memory and can improve caching 
efficiency - this
   is good for readahead where pages are quickly faulted in with less 
I/O and cached in
   compressed form.

   So it depends on the disk characteristics and the compression 
algorithm whether compression
   will yield a benefit. CD/DVD devices are much slower when compared to 
harddisk and Zlib
   compression on data on CD/DVD always yield benefits. CD/DVD are 
random access but
   sequential-seek media due to a spiral track. So seek time is an 
important overhead. This is
   also borne out by the hordes of Linux LiveCDs that use cloop and my 
experience with
   BeleniX and LiveMedia projects. It only DVD-RAM media that has 
concentric tracks. Using
   Bzip2 however on CD/DVD is counterproductive because of relative 
slowness of Bzip2
   decompression which can cause the DVD drive to spin down while the 
CPU is busy
   decompressing pages.

   Even in the case of ZFS, using lzjb compression on fast harddisks 
still yield improved I/O
   performance. However Zlib compression has significantly more overhead 
than lzjb and may
   not yield a benefit when used in conjunction with fast harddisks. See 
the following blog
   entry:

   http://blogs.sun.com/ahl/date/20070131

   Apart from compression, re-ordering data on CD/DVD is crucial. Due to 
their sequential
   seek nature data re-ordering reduces drive head seeks which even 
benefits a random-access
   LiveCD boot scenario, so it should have big a benefit for Install 
since that is essentially a
   sequential operation.

   Apart from all these there are many other factors that affect 
performance when running from
   CD/DVD:

   http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story2
   http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story1
   http://blogs.sun.com/moinakg/entry/the_belenix_livecd_performance_story

Regards,
Moinak.