The readahead mechanism in readahead-list service currently in portage is very static. I discuss a mechanism based on 'lsof' which can be used to build up 'interesting' prefetch database in the topic here: http://forums.gentoo.org/viewtopic-t-478491.html I have seen some very good speedup during boot with this approach. Does anybody here think that it is a good idea and we can build something similar into readahead-list by making it a daemon based and making it little more intelligent e.g. it could keep pdating the database by adding more frequently used files (upto a maximum size) and removing which are used only transiently? Also, it could schedule the actual read of the database better than the script in the post above does. Just an idea I wanted to throw at people here. Its not really a bug but I didn't know how else to do it.
Don't restrict bugs without any reason. Leave the checkboxes alone, please.
As the author of readahead-list, I'm glad to see more activity on this front. However making it a daemon provides no gain, the startup overhead is very small. I will however read what I had said in the previous bug about readahead - somebody needs to get out the syscall audit support in 2.6.17 (with sufficently updated kernel headers and the userspace audit app), and tell audit to log EVERY open syscall, and then use that to build up a decent profile for booting. There's a few parts: 1. We should provide a reasonable list for the boot runlevel. Very few users change this much, so it's reasonably simple. 2. The common stuff for the default runlevel should also be made into a list, that users can then modify said list as per their needs. 3. Some of the Redhat folk previously suggested an interesting modification to the runtime linker (ld.so) - at the run of any ELF binary with a special section, read that section to see the location of a readahead profile, and then start a background fork that loads the specified readahead profile. This would hugely benefit most Linux GUI applications.
*** This bug has been marked as a duplicate of 64724 ***
