> > There have been experiments with live "preloading" files used at boottime, > > but as since these files are stored all over the disk this hasn't knocked > > off that much time. In the end someone tried copying the files needed at > > boottime to a new partition so the boot files were all next to each other, > > and after that copying the rest of the filesystem. This worked much better, > > but it's a rather cumbersome thing to do (need to pick files, takes lots of > > time to copy, etc. etc.). With cachefs everything should be solved > > automagicly. > > Linus suggested something like this, and yes it would be possible. It would > give you a block-by-block sequence of what page of what file is needed when. > > > So basicly the next part of my question is, would say a 128MB cachefs > > partition help in the bootprocess by bringing all the files together? > > (transparent copies of the files, that is) > > Theoretically, yes; if you want to make ext3 or whatever you use for your > rootfs use cachefs. Cachefs on a blockdev would make more sense for this than > Cachefs on scattered files as you'd then be governed by the underlying > filesystem's method of laying out. You'd probably also want some daemon or utility that can re-order the blocks in cachefs so that when you boot, you can read the 'cacheboot' partition in sequentially, with no seeks. The last time I timed a bootup on my other 600mhz powerbook under Debian to a usable KDE screen, it was faster than MacOSX.. But then I have 1GB of memory in my laptop.. so everything gets cached in RAM. However, the seeks are also a big deal.. if there is enough intelligence to read a whole cacheboot partition in at once, if it's 128MB, it'd take about 4 seconds with my laptop hard drive. My laptop currently has 548 files open, and I have KDE, firefox, mozilla-thunderbird, and konqueoror open. As a naive assumption, if every file is contiguous, that's 500 seeks, at an average time of 10ms/seek, that's 5 seconds of time spent seeking, not counting any data transfer. This doesn't count any files that get opened, accessed and closed before bootup. So, it's reasonable to speculate that you can get the file load component of bootup improved by *at least* a factor of two.
