ureadahead should have config option to disable or force ssd/hdd mode

[Sitsofe Wheeler]

Some cheap/old SSDs fail to report their non rotational nature to the kernel. This results in ureadahead treating them as a rotational disk, which can actually cause slower boot times than not using ureadahead at all. There should be a config option to allow affected users to correct this by either forcing ureadahead to ssd mode, or disabling it entirely. Preferably this should be in /etc/default and/or configurable via debconf so a simple dpkg-reconfigure will suffice.

[Sitsofe Wheeler (sitsofe)]

I've done some testing and the results are shown in the attached bootcharts.

To disable ureadahead I modified /etc/init/ureadahead.conf so that
exec /sbin/ureadahead --daemon
was changed to
#exec /sbin/ureadahead --daemon
(this applies to bootcharts 1, 4 and 10). This was reversed to re-enable it for other steps.

Before bootchart 5 I modified /etc/init/ureadahead.conf so that
start on starting mountall
was changed to
start on started udev
. This changed remained for all later bootcharts.

Before bootchart 8 I added the attachment 10-ssd.rules to /etc/udev/rules.d/ . This change remained for all later boot charts.

Here's a summary of times and the settings used to make the bootcharts:
1 - Time 25.57. Boot with disabled readahead.
2 - Time 25.68. Boot performing profiling. ureadahead.conf is starting mountall. Pack generated is pack-rotational-1 .
3 - Time 27.57. Boot with readahead.
4 - Time 27.01. Boot with disabled readahead.
5 - Time 27.35. Boot with readahead. ureadahead.conf modified to started udev . (Pack used is pack-rotational-1 as made in 2)
6 - Time 25.68. Boot performing profiling. Pack generated is pack-rotational-2 .
7 - Time 27.25. Boot with readahead.
8 - Time 25.57. Boot performing profiling. 10-ssd.rules added to /etc/udev/rules.d/. Pack generated is pack-ssd-1 .
9 - Time 24.47. Boot with readahead.
10 - Time 25.51. Boot with disabled readahead.

[Sitsofe Wheeler (sitsofe)]

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.

[Sitsofe Wheeler (sitsofe)]

I misreported bootchart 4's time it should have been:
4 - Time 25.01. Boot with disabled readahead.

Further testing shows that ureadahead IS seeing the udev rule's changes even when launched at the mountall stage so my previous comment saying it wasn't is in error. Perhaps what threw me is that ureadahead decides whether it should use hdd or ssd mode by what is in the pack rather than what /sys is currently reporting.

[lavinog (lavinog)]

This could be a bug with the drive itself. 32MB/s seems really slow for a SSD.

Maybe it would help if you post the specifics about your drive:
sudo hdparm -i /dev/sda

[lavinog (lavinog)]

According to this site: http://jkkmobile.blogspot.com/2008/05/asus-eee-pc-ssd-read-and-write-tests-4g.html
32MB/s seems about right for a 16g 900. The 4g version reaches 44MB/s.

I thought kerneloops was disabled in the final release, but it is shown in your bootcharts. Are you sure you are running the latest updates?

[Scott James Remnant (Canonical) (canonical-scott)]

On these SSDs, could you provide the output of "cat /sys/block/sda/queue/rotational"

[Sitsofe Wheeler (sitsofe)]

lavinog:
I like to report kernel issues in my spare time and have manually turned the kerneloops service on. You will see that many other services are missing from the bootchart as I have manually turned them off. As it happens I don´t think I was running the latest updates but the updates that have been released are irrelevant to this issue...

Scott:
As I tried to state in comment #17, such cheap/1st gen SSDs will be misreported as being rotational: i.e. /sys/block/sda/queue/rotational is 1 on an out of the box install on an EeePC 900 16G SSD. If this were not the case I would not need to manually add the udev rules given in comment #15 to workaround this issue. My concerns are twofold:
1. Some SSDs don´t report they are non-rotational. This leads ureadahead to use a mode that will actually slow down boot.
2. A pack caches the fact that the disk was originally reported as rotational so until the pack is remade the udev change is not picked up.

Is that clearer?

[Peter Petrakis (peter-petrakis)]

I've begun pushing a patch upstream to fix the root cause of this issue. It basically boils
down to adding a new libata quirk and blacklisting the broken drives so they report
themselves correctly.

http://marc.info/?l=linux-ide&m=128337091000406&w=2

It's a simple patch to integrate and expand upon yourself. Just determine what
your model name is and add a new entry to the blacklist as shown in the patch.

This can be easily divined by installing the sg3-utils package and running the
following command:

$ sudo sg_vpd -p ai /dev/sda
ATA information VPD page:
  SAT Vendor identification: linux
  SAT Product identification: libata
  SAT Product revision level: AGLA
  ATA command IDENTIFY DEVICE response summary:
    model: TOSHIBA THNS128GG4BAAA-NonFDE
    serial number: 10US10BTT02Z
    firmware revision: AGLA0203

Use the entire model: value when adding a device to the blacklist.

I don't think it would be palatable to upstream to have a dictionary of 'broken' SSD drives. I expect
a device tree like driven solution to eventually take hold to move or complement the blacklist outside
of the kernel completely.

[Id2ndR (id2ndr)]

I just remove the package ureadhead in natty and my system boot much faster (8.38s without ureadhead). Be noticed that it seems that removing the package make the computer shutdown.