On Tue, 04.10.11 19:38, Adam Williamson (awill...@redhat.com) wrote: > > On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote: > > On Tue, Oct 4, 2011 at 3:32 PM, JB <jb.1234a...@gmail.com> wrote: > > > Let me append "The Blame Game". > > > # systemd-analyze blame > > > 32983ms livesys.service > > > 22828ms NetworkManager.service > > > > That timing for NM is so vastly different than what I'm seeing on my > > installed F15 system. I am intrigued. > > His numbers are all huge as he's booting live, either from an actual > rotating shiny disc thing (the antiquity of it all!) or a USB stick. > Either of which is going to be slower than an HD or SSD.
If this is indeed a boot from CD then it's not really surprising our numbers are bad since seek times on CDs are awful. If people want to spend optimizing the boot time here it should be possible to reorder the files on the squashfs image to minimize seeking. mksquashfs has the -sort option for that. The data would have to be generated in a two-pass way: first burn and boot the unordered image, use it to determine the access order, then pass that to mksquashfs and generate a second, ordered image. You could use systemd-readahead-collect to collect that access order information, but you'd need to write a tool to convert systemd's format to something readable by mksquashfs. Optimizations like this are always thinkable, but then again spending the time on optimizing CD boots sounds like a lot of time wasted on yesterday's technology. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
