Bug 115752

Summary:	readahead should support directory recursion and a -f filelist option and document them via a man page
Product:	[Fedora] Fedora	Reporter:	Richard Lloyd <rkl>
Component:	kernel-utils	Assignee:	Dave Jones <davej>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	pfrields
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2004-11-19 03:34:44 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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):
kernel-utils-2.4-9.1.115

How reproducible:
Always

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
/usr/sbin/readahead

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?).