Red Hat Bugzilla – Bug 115752
readahead should support directory recursion and a -f filelist option and document them via a man page
Last modified: 2015-01-04 17:04:33 EST
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
Version-Release number of selected component (if applicable):
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 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.
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
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?).