CD optimization

John dingo at coco2.arach.net.au
Fri Sep 17 10:24:22 CDT 2004


Matt Zimmerman wrote:

>I had to do a couple of installs in order to debug #1143, and along the way,
>I started to take an interest in the time taken by archive-copier.  It seems
>that by the time archive-copier runs, the data loaded into cache by
>cdrom-detect has been lost, because I see the same slow seeking behaviour as
>I saw previously with debootstrap.
>
>So, on a second round, I ran a "while true; do find /cdrom/ >/dev/null;
>sleep 1" on console #2.  This held the data in cache, avoided all of the
>seeking I was seeing, and subjectively sped up both debootstrap and
>archive-copier by a good margin.
>
>Therefore, it would appear that the idea has great potential, but that we're
>not successfully exploiting it yet.  The approach I used above seems awfully
>heavy-handed, but I don't immediately see any other way to coerce this stuff
>to stay in cache.  Any ideas?
>
>  
>
I was thinking about install speed a little while ago. It's long seemed 
to me that using debootstrap at install time is flawed: surely just 
unrolling a tarball is faster?

Open one file on the CD and (more-or-less) stream the data off it.

Also, order of the packages on the CD should be the same as the install 
order. If you don't know what that is, do an HTTP install and view the 
webserver logs.






More information about the sounder mailing list