remove readahead from default package set (was Re: should readahead allow generic paths?)

Karel Zak 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?
> >
> >Bill
> >
> 
> 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 
> patterns.

 you needn't this scenario, you can simply boot with

    init=/sbin/readahead-collector

 it's probably better than develop and maintain something like
 template lists.

 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

-- 
 Karel Zak  <kzak at redhat.com>




More information about the fedora-devel-list mailing list