Feature changed by: Ralph Ulrich (ulenrich) Feature #305326, revision 17 Title: 5 Second Boot openSUSE-11.2: Rejected by Stephan Kulow (coolo) reject date: 2009-02-09 15:47:52 reject reason: Sorry to be harsh, but this feature can't be implemented as asked for. Priority Requester: Mandatory Requested by: Jared Allen (jpallen) Partner organization: openSUSE.org Description: The amount of time required to boot up needs to be reduced drastically. I suggest we consider the work being done in this article: http://lwn.net/Articles/299483/ as our baseline and strive to make similar adjustments. Business case (Partner benefit): openSUSE.org: As we continue to get more involved in the Thin Client and UMPC markets, boot time becomes increasingly important. Intel's Moblin project is touting boot time as one of the significant features/advantages of their Moblin project. There are signs that other distros are following suit. We have at least one Thin Client partner that is requesting significant improvements in boot time in order to remain competitive. In fact, SLETC would have been included on more thin client hardware shipments to-date had we a faster boot time. Discussion: #1: Jared Allen (jpallen) (2008-10-06 17:03:30) I spoken with both AJ and Michael Meeks regarding this requirement. AJ suggested that include Coolo in the discussion since it will most definitely affect the distribution as a whole. #2: Stephan Kulow (coolo) (2009-01-20 15:18:14) similiar adjustments? Do you mean the "We had to do a lot of damage to X," part or the "use xfce" part? There is a limit on what you can do in a generic system and many of the low hanging fruits is already done. If you talk about getting a thin client to boot fast, then making transparent use of suspend & resume is the way to go IMO. Booting off cold hardware is problematic if you want more than xfce. There are about 100MB data to read for a pretty standard KDE session (and I assume GNOME is similiar) - on a pretty fragmented file system you get ~8MB/s netto - so just reading your files takes already 12s. Making preload dynamic on the blocks actually used is something that was discussed long, long ago, but the kernel still doesn't provide the infrastructure - so this is one of the TODOs, but possibly Intel got that ball rolling. Kernel drivers being quicker with probing would be another TODO, also listed in the article. Another urgent TODO is defragmentation because readahead helps only a little if the next update will scatter the files around your 1TB hard drive. #3: Jean-Daniel Dodin (jdd) (2009-02-15 10:28:27) may be this is plain stupid, forgive me if it is. The install time was dramatically reduced by the use of "images" of installs. Could it not be possible to build "images" of the installed system - that is to have all the necessary files on boot able to read at once. It's not exactly the same as suspend to disk, of like a suspend to disk with only the system. Most computers never change hardware and a new grub entry could be added: boot with new hardware + #4: Ralph Ulrich (ulenrich) (2009-08-05 23:14:17) + Squashfs could be utilized for that. It would be superior to preload as + it also could do the initrd thing. But every time a /bin/lib is updated + the whole squash-start-image needs to be updated also. Andthere it is + to make sure such an image is not fragmented on disk. -- openSUSE Feature: https://features.opensuse.org/305326