Fedora 16 beta vice Knoppix
kay.sievers at vrfy.org
Wed Oct 5 13:15:10 UTC 2011
On Wed, Oct 5, 2011 at 15:09, Lennart Poettering <mzerqung at 0pointer.de> wrote:
> On Tue, 04.10.11 19:38, Adam Williamson (awilliam at 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.1234abcd at 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.
Might be interesting to just compare the CD boot speed with the same
image on a USB stick. That should giva an idea.
More information about the devel