Lucid OEM install slow - possible to speed up the process?

[NoOp]

On 04/29/2010 09:39 AM, NoOp wrote:
> On 04/29/2010 02:46 AM, Carsten Agger wrote:
>> NoOp wrote:
>>> On 04/28/2010 11:02 AM, Carsten Agger wrote:
>>> ...
>>>> Now I benchmarked them using the same USB key and USB socket.
>>>>
>>>> Alternate install with OEM option, one hour twenty minutes.
>>>>
>>>> Live CD with OEM option, fifteen minutes.
>>>>
>>>> The alternate CD is doing something differently.
>>> 
>>> You might consider filing a bug report:
>>> https://bugs.launchpad.net/ubuntu/+source/ubiquity
>>> 
>>> 
>>> 
>> Did now,
>> 
>> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/571628
>> 
>> Filed it against debian-installer as this seems to be more precise, 
>> given that ubuquity is what runs on the live CD.
>> 
>> Feel free to change if you think that is wrong :-)
> 
> Wow... that tends to open ones eyes to ext4 issues. I see Colin Watson
> marked it as 'Won't Fix', but looks very much like a dupe of the bug
> pointed to in the release notes[1]:
> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/570805
> [[regression] dpkg fsync cause massive regression in Ubuntu Server and
> Alternate installation times]
> 
> I wonder what your oem install time would be with ext3; perhaps you can
> test?
> 
> 

Sorry, for others on the list I forgot to add a link to the release notes:
[1] http://www.ubuntu.com/getubuntu/releasenotes/1004
[Performance regressions with ext4 under certain workloads]
<quote>
In particular, the dpkg package manager is known to run significantly
slower on ext4, causing installations using the server or alternate
install CD to take on the order of twice as long as before. ext4 does
not guarantee atomic renames of new files over existing files in the
event of a power failure shortly after the rename, and so dpkg needs to
force the contents of the new file out to disk before renaming it in
order to avoid leaving corrupt zero-length files after power failures.
This operation involves waiting for the disk significantly more than it
strictly needs to, and so degrades performance. If fast package
management operations are most important to you, then you should use
ext3 instead. (570805)
</quote>