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