Still present in FC3T3.  Changing version from 'test1' as originally
suggested :( to fc3test3.

Still there is FC3 :-(

I can confirm this. Specifically I see that /etc/readahead.files
contains references to evolution-1.4, when evolution-2.0 is what
ships. Consequently a large number of files referred to in
/etc/readahead.files doen't actually exist (and evolution loads slow,
defeating the whole point of having readahead).

The build process for this package should do some sort of regression
test to make sure the files referred to actually exist so that this
doesn't happen it the future. 

IMHO the current approach is simply not very viable - it is a bit
crazy to have to release a new version of the kernel-utils package
every time some other package is updated. I think that what needs to
be done for FC4 is that instead of (or in addition to)
/etc/readahead.files there needs to be a /etc/readahead.files.d
directory that various packages (like evolution) would put their lists in.

Ideally, chkconfig would know about those as well - this way chkconfig
could enable /etc/readahead.files.d/foo when service foo is enabled
and disable /etc/readahead.files.d/foo when service foo is disabled.
CC'ing chkconfig owner.

Nah, what's needed is a daemon that actually tracks what the system is
using on each boot and populates that.

Of course, without disk block reordering, readahead does't really help
anyway.

I've written a Perl script which may for a basis for such a daemon. Currently,
one has to manually generate trace file using strace, e.g. for tracing KDE
startup initiated from KDM I have to strace two kdm processes and the X process
(PIDs 3703, 4100 and 9573):

strace -f -F -p 3703 -p 4100 -p 9573 -e trace=open,process -o
/etc/readahead/strace.kdm

My script parses such a file and outputs unique filenames in the order they are
extracted. At the same time, it sums ups the total size of files output so far,
and when it exceeds 1/2 of the amount of total physical RAM, it exits.

I run strace_open_extract_names_for_readahead.pl < /etc/readahead/strace.kdm >
/etc/readahead.files to update my readahead.files.

The other parts that are missing are:
   * an enhancement to /etc/X11/prefdm, which would occasionally (e.g. every 30
logins or 30 days) attach with strace utility to the X display manager, and
update the /etc/readahead/$DISPLAYMANAGER with correct (strace_of_displaymanager
| strace_open_extract_names_for_readahead.pl) list of files
   * an enhancement to /etc/init.d/readahead so that it uses
/etc/readahead/strace.$DISPLAYMANAGER that's correct for a the display manager
set in /etc/sysconfig/desktop

Anyone willing to do that?

Created attachment 113401 [details]
The Perl script to extract open/exec-ed filenames from a strace output file

The script accepts 2 optional arguments:

  -t: summarize the total size of files that were output (in bytes)
  -m: summarize the total amount of physical RAM detected (in bytes, rounded to
the nearest KB)

It uses the vmstat utility to discover the amount of physical RAM.

"Nah, what's needed is a daemon that actually tracks what the system is
using on each boot and populates that."

s/on each boot/periodically via cron

Otherwise, we're defeating the purpose of speeding up boot.  Right?

Recording a list of files opened is not *necessarily* excessively time-consuming.

And "periodically via cron" makes no sense at all, because:

1) cron starts as one of SysV services itself, when a significant part of boot
process is already done
2) a cron job will likely start much later, when there certainly are no bootup
processes to monitor for file open activity.

A more correct approach would be to launch that information collecting
daemon/utility on boot, but not on _each_ boot, only on some boots, e.g.:

"every 10th boot, or if more than month has passed since the last run."

Files regenerated in 1.1-1.11.

Can probably take discussion of geernation of file lists over to bug 156442.