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