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