remove readahead from default package set (was Re: should readahead allow generic paths?)
kzak at redhat.com
Mon Oct 15 21:00:53 UTC 2007
On Fri, Oct 12, 2007 at 01:05:18AM -0400, Warren Togami wrote:
> Bill Nottingham wrote:
> >Eric Sandeen (sandeen at redhat.com) said:
> >>Matthias Clasen wrote:
> >>>On Thu, 2007-10-11 at 09:20 -0500, Eric Sandeen wrote:
> >>>>Tossing a default list out there and hoping for the best probably won't
> >>>>work, at any rate.
> >>>So are we going to get your fixed lists into F8 ?
> >>Well, part of the problem is that "my" fixed lists may not be everyone's
> >>fixed lists - I generated a custom list from *my* boot sequence. Coming
> >>up with a good default list that actually speeds *everyone's* boot time
> >>is another issue. If we think it's worth the 4 second or so boottime
> >>reduction, maybe some way to automatically generate the custom lists
> >>during firstboot might be an option. But then, they will rot over time...
> >Given that, is there any reason to ship it on by default at this point?
> Relatively simple solution:
> 1) Ship readahead with template lists. This includes a list of commonly
> used stuff. It could include wildcards like /usr/lib*/firefox*/foo in
> order to handle multilib and version numbers changing.
> 2) During firstboot and occasionally after boot, something generates the
> actual readahead file lists based upon several factors like:
> - is the file actually installed?
> - is the service enabled?
> Later improvement:
> 3) Sometime later, more intelligent software could be included to help a
> user update their readahead lists based upon their own software usage
you needn't this scenario, you can simply boot with
it's probably better than develop and maintain something like
The problem is something completely different than contents of
/etc/readahead.d/. The problem is that readahead (also with perfect
list of files) provides poor performance improvement.
We need to spend time with more promising tasks like better init
scripts, faster rhgb/X, swsuspend, fscache, ...
IMHO, the readahead package is poor workaround with no future. (I'm
author of more than 70% of the code.)
Karel Zak <kzak at redhat.com>
More information about the fedora-devel-list