Comment 17 for bug 577763

I should note that ureadahead does not see the updated udev rules introduced at step 8 on boot when ureadahead.conf contains starting mountall. Perhaps I could include a bootchart demonstrating this...

Conclusions (don't read this until you've made your own mind up as to the problem!):
There are many devices that do not correctly inform the kernel of their properties and these make a mess of doing things automatically. It is possible to workaround this using udev rules but these are of little use to ureadahead in its current configuration.

Using hdd settings (in terms of order of files in the pack and blocking boot until readahead is finished) on an SSD is detrimental to boot speed - it is better to have no readahead than the wrong settings.

ureadahead's initscript could do with configuration in /etc/default/ to make turning it off easier and to force hdd/ssd mode as it starts too early to see updated udev rules, waiting until udev has finished takes too long and waiting for a udev event seems like a lot of work which someone adding udev rules would have to be aware of.

There is probably nothing that can be done automatically for cheap SSDs that incorrectly announce their abilities to the kernel other than a config option if they are detected at install time. This may also impact ureadahead on LiveCDs that are actually running off USB keys...

The problem is actually worse when the amount readahead to be performed is bigger (e.g. user starts a browser after everything is ready). I may see if I can include a bootchart demonstrating this too.