[Fedora-livecd-list] boot speed optomization (Qs for DZ mainly)

[Jane Dogalt]

David,

I just read the historic readahead post you referenced.  I haven't
really spent any effort thinking about massaging readahead into a boot
speed optomization for a livecd (I'm guessing you have?).

But it happens to be very similar to the 'early boot file seperation'
methods I've described here relating to livecds.  I have a couple
questions about your 2004 post-

"
I've made the following observations

1. The kernel patch, linux-2.6.3-printopen.patch, wasn't really working
   well for me - it reported far to few files - instead I added a
   printk() to fs/namei.c:link_path_walk() 
   (disclaimer: I don't know much about the kernel so there may be a
   better solution than this). 
"

The method that I was planning on implementing, was to boot a
livecd(-to-be) under qemu, then use file access times to construct a
list of files that should be precached (same thing as readahead
afaict).
(And then by hand figure out files that are specific to the hardware
platform, and make sure that their cousins get included in the list)

What are your thoughts on this?  Any quick reason why this wasn't used
for readahead (I'm fairly ignorant of the internals of readahead).

And do any of the reasons why it wasn't used for readahead apply to
livecd optomization case?

FYI- I see 2 obvious ways to do readahead in the livecd case.  One,
which I've outlined here before, would be to use unionfs, and seperate
the filesystem images into "files that should be read ahead" and "the
rest".  Obviously unionfs, while it may eventually get into fedora,
isn't the way to go.

Its only a minor modifcation to do the same thing with devicemapper
snapshots however.  (i.e. you create the filesystem populating it with
the files to be read-ahead, then you dm-snapshot it, and copy the rest
of the files in.  The resulting original fsimage(sparse ext3) along
with the devicemapper snapshot device (damage/cow) image file,
constitute the same effective thing as above with unionfs.

Thus all your early read-ahead files, go in a single file/track on your
cd/dvd, reducing seek times.

Additionally, you can just read the read-ahead section into ram in one
big chunk.  (that would waste some ram, however with md-mirror tricks,
you can work around that)

Another minor question-

"
b. ext3 should support operations for moving blocks around; e.g.
    optimize around the readahead fileset - when idle the system should
    rearrange the files to facilitate faster booting
"

Has anything happened with that in the last 3 years?  Sounds like a
decent idea, that might be adaptable to the livecd boot optomization
case.

Final question:  Have you had any other ideas on how livecd boot speed
might be improved?

-dmc/jdog


 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news