Bug 128444 - /etc/readahead.files needs to be updated
/etc/readahead.files needs to be updated
Product: Fedora
Classification: Fedora
Component: kernel-utils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
Depends On: 158130
Blocks: FC4Blocker
  Show dependency treegraph
Reported: 2004-07-22 18:32 EDT by Ben Smith
Modified: 2015-01-04 17:08 EST (History)
7 users (show)

See Also:
Fixed In Version: 1.1-1.11
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-18 22:15:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The Perl script to extract open/exec-ed filenames from a strace output file (1.93 KB, text/plain)
2005-04-20 06:01 EDT, Aleksander Adamowski
no flags Details

  None (edit)
Description Ben Smith 2004-07-22 18:32:16 EDT
Description of problem: 
/etc/readahead.files contains filenames for versions of software 
that is no longer included in FC3. 
Version-Release number of selected component (if applicable): 
Additional info: 
/etc/readahead.early.files may also need to be updated.
Comment 1 Ben Smith 2004-10-27 12:04:50 EDT
Still present in FC3T3.  Changing version from 'test1' as originally
suggested :( to fc3test3.
Comment 2 Aleksey Nogin 2004-11-28 22:54:35 EST
Still there is FC3 :-(
Comment 3 Aaron VanDevender 2004-12-26 01:41:18 EST
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. 
Comment 4 Aleksey Nogin 2004-12-27 18:27:57 EST
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.
Comment 5 Bill Nottingham 2004-12-28 00:47:41 EST
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
Comment 6 Aleksander Adamowski 2005-04-20 05:54:12 EDT
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

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?
Comment 7 Aleksander Adamowski 2005-04-20 06:01:14 EDT
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.
Comment 9 Ben Smith 2005-05-16 15:08:50 EDT
"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?
Comment 10 Bill Nottingham 2005-05-16 15:11:36 EDT
Recording a list of files opened is not *necessarily* excessively time-consuming.
Comment 11 Aleksander Adamowski 2005-05-17 09:47:50 EDT
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.

Comment 12 Aleksander Adamowski 2005-05-17 09:55:51 EDT
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."
Comment 13 Bill Nottingham 2005-05-18 22:15:11 EDT
Files regenerated in 1.1-1.11.

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

Note You need to log in before you can comment on or make changes to this bug.