cloud-init disables ureadahead even when it might be useful
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
cloud-init (Ubuntu) |
Triaged
|
Low
|
Unassigned | ||
ureadahead (Ubuntu) |
Confirmed
|
Low
|
Unassigned |
Bug Description
Since bug 499520, cloud-init currently disables ureadahead by using a dpkg-divert of /etc/upstart/
a.) ureadahead was causing OOM on boot small vms (~ 300M)
b.) ureadahead inside a VM doesn't generally make any sense. Ureadahead tries to optimize disk reads for ssd or spinning disks. Its methods of determining if the disk of the system is ssd or spinning won't work in a VM.
c.) ureadahead is part of ubuntu-minimal task, and we did not want to change that.
Recently, though, we've started using cloud-init on real hardware, where ureadahead could be of use.
Thus, I'd like to have a better solution. I think ureadahead would ideally disable itself if it found one of the following conditions:
1 small amount of memory (<512 or even 1024M)
2 if it is running in a container
3 no definitive knowledge of the type of disks used (if it thought this might be a VM)
Of those options, determining the first 2 are straight forward, and I would think could be done in the upstart job even. I'm not familiar enough with ureadahead to know how easily it would be to determine number 3.
Related bugs:
* bug 499520: default uec-image requires at least 300 M of RAM to run - m1.small and c1.medium not needed by default
description: | updated |
Changed in ureadahead (Ubuntu): | |
importance: | Undecided → Low |
Sounds like it should check both that it is not in a container, and that it has >= 512M (or something) ram?