Tar output mode for installworld

[Matthew Dillon]

:...
:>> files off of CD.
:> 
:> True, but couldn't we optimize the ISO layout so it will be a near
:> sequential read of the CD?
:
:Hmmm...  This might work.  The prototype 'ntree' support
:I posted should be sufficient for people to experiment
:with these ideas.
:
:Cheers,
:
:Tim Kientzle

    Probably the best way to do this is to pre-cache the data with an
    /etc/rc.d script.  Write a little program to do it or build it as a
    script.  Inode numbers for files on a CD tend to reflect the location
    of the file on the CD so a quick pre-scan of primary directories,
    extract the file paths used during the boot, sort by inode number, and
    then just open/read them to force them into the buffer cache ought to be
    sufficient.

    I would not try to optimize the layout of the ISO itself as such work
    would likely go stale in fairly short order and would be difficult to
    maintain.

    Personally speaking I think its a waste of time to worry about it.
    Sure the CD seeks around a bit, but most modern CD drives do have
    caches and it really isn't all that bad.

    Instead, we focus on streamlining the process so a person can go through
    a few quick menu items and then take a short coffee break while the
    installer does the rest of the work.

    --

    I do recommend the 'copy the live CD to the hard disk' method of
    installation.  It removes a lot of confusion from the release building
    process and makes it utterly trivial to add customizations.  The only
    thing we can't copy directly is /etc, because the /etc on the CD is for
    the CD boot.  So the DragonFly CD has a "/etc.hdd" directory for the
    version of /etc to be installed on the HD.  Also, large chunks of the
    infrastructure will already be in the buffer cache just from booting
    the live CD so those bits don't have to be re-read.  Doing a direct
    copy has always felt 'faster' to me then unpacking split up tar files.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>