Bug 115752 - readahead should support directory recursion and a -f filelist option and document them via a man page
Summary: readahead should support directory recursion and a -f filelist option and doc...
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel-utils (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-02-15 18:43 UTC by Richard Lloyd
Modified: 2015-01-04 22:04 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-19 03:34:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Richard Lloyd 2004-02-15 18:43:13 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.6) Gecko/20040115

Description of problem:
The /usr/sbin/readahead binary, part of kernel-utils, strangely only
takes filenames as parameters, whereas it should probably also allow
directories to be specified (which would be recursed for actual files)
and maybe also a "-f filelist" option (a file containing a list of
files and dirs to readahead). It would also be nice for readahead to
have a man page if these features are added, so people know it's got
them :-)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Look at the /etc/init.d/readahead script.

Actual Results: The parameters passed to /usr/sbin/readahead in
/etc/init.d/readahead have to be clumsily wildcarded because
/usr/sbin/readahead doesn't support directory recursion. There could
also be command line length issues with the wildcarding or if the file
/etc/readahead.files has a large number of entries - to kludge around
this, /etc/init.d/readahead runs the readahead binary 4 times !!

Expected Results:  Parameters to the /usr/sbin/readahead should allow
directories to be specified, which would be recursed for files. If it
had a "-f filelist" option, then "-f /etc/readahead.files" would be
used instead of the clumsy `cat /etc/readahead.files` that's there at
the moment.

Additional info:

The source code to the /usr/sbin/readahead binary also has a minor
issue that should be fixed - if the open() statement succeeds, but the
following fstat() fails, the code returns from the function without
close()'ing the currently open file. Not a big issue because the OS
will close those open files when the binary exits, but there's a
potential for a lot of fstat() failures to cause the maximum number of
open files to be exceeded.

Comment 1 Dave Jones 2004-11-19 03:34:44 UTC
recursing through directories doesn't make any sense, as theres no guarantee we
want to read _every_ file in the sub-tree into cache.

as for the exec'ing 4 times - here, strace shows exactly one call to

Comment 2 Richard Lloyd 2004-11-19 10:50:11 UTC
It looks like /etc/init.d/readahead has been (thankfully) revamped in
Fedora Core 2 and 3 and now no longer runs the readahead binary
multiple times. It has, however, been split into two separate scripts
in /etc/init.d - readahead and readahead_early. The only difference is
their position in the boot sequence and that one uses
/etc/readahead.files and the other uses /etc/readahead.early.files.

However, some of my issues still remain - /etc/readahead.files is now
43K (!!) long and contains 943 files. It seems to me that the ability
to specify wildcards and/or directories would be very useful to cut
down the size of /etc/readahead.files and also make it more
maintainable. It's also lucky that bash has a very large max command
length (250K?) otherwise the `cat /etc/readahead.files` could have run
into trouble (hence my plea for a -f option or maybe it could read
from stdin if no file is specified?).

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