Fedora 10 - Boot Analysis
Hardware: Asus EeePC 901 with a flash disk.
Time taken from entering the encrypted root disk password until the password can be entered (after pressing return in gdm). The 10 second wait in nash is ignored here (which really annoys me and seems to be fixed in newer mkinitrd versions).
Default Live CD Installation: 39s (bootchart)
After installing readahead and running one collection boot process: 36s (bootchart)
At this point, I recognized that all processes (like newaliases), which call a fsync(), let the boot process wait until all data is written to disk. This is the same effect as the firefox sqlite fsync bug.
Mounting the root filessystem with relatime and turning off ordered data writing for the journal with
# tune2fs -o journal_data_writeback /dev/root
improved the situation (even though data might be old on the disk after a crash, but ext3 does not force the disk to empty the write cache anyway).
Turning off setroubleshoot and fixing https://bugzilla.redhat.com/show_bug.cgi?id=476023 and https://bugzilla.redhat.com/show_bug.cgi?id=476028: 32s (bootchart)
Turning off bootchart: 30s
So all in all we have nearly accomplished the 30 Second Startup Feature.
To reach the 20 Second Startup Feature, we really have to tackle setroubleshootd. Also we might start to move basic services to upstart and start them in parallel (bootchart with some services moved). Parallel booting will show no benefits with readahead and a small amount of active services, but the more services are turned on, the more you benefit with a parallel boot setup. Moving more basic modules to be compiled in the kernel also would gain some seconds. Speaking about modules, I ported Jakubs modprobe patch to the recent 3.6pre1 module-init-tools version. Though it nearly halves I/O, it would only safe us a fraction of a second here (not recognizable).
Follow the discussion on fedora-devel.