http://www.harald-hoyer.de/personal/blog/fedora-10-boot-analysis
A brief 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 should be configurable in /etc/sysconfig/mkinitrd).
Default Live CD Installation: 39s (bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-nonread.png)
After installing readahead and running one collection boot process: 36s
(bootchart
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead.png)
At this point, I recognized that all processes (NetworkManager and 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
http://shaver.off.net/diary/2008/05/25/fsyncers-and-curveballs/.
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
http://www.harald-hoyer.de/files/f10boot/bootchart-readahead-nosetrouble.png)
Turning off bootchart: 30s
So all in all we have nearly accomplished the 30 Second Startup Feature
http://fedoraproject.org/wiki/Features/30SecondStartup.
Well, no; not if this requires data=writeback. We can't ship that way,
it's a potential security hole. You don't want someone's maildir
suddenly containing pieces of /etc/shadow or whatnot. The old data that
may be exposed by data=writeback may not belong to that user.
-Eric