Hi Andre, On Monday 07 September 2009 14:26:25 Andre Beck wrote: > Hi, > > switching to readahead-fedora and defaulting to dash shaved another 2s > from my boot time (now at 13s), so thanks for packaging this advanced > version of the original readahed. Now for what bothers me:
Good to hear that. Just wondering, have you tried any of the other two readaheads? how did they perform on your machine? > > When booting in profiling mode, I noticed a delay before I could log > into the system, but first attributed it to the overhead of profiling > (coming from the original readahead[1] package, it still appeared fast). > Later I modified READAHEAD_EXTRA_COLLECT by bumping it up to 30s in > /etc/default/readahead-fedora, where it became clear upon next profiling > that the delay observed is actually stop-readahead-fedora blocking, > sleeping for that amount of time in the foreground. Testing a change I'm going to introduce on the next upload I managed to make the profiling step only take two more seconds than a normal boot (given that early-readahead is the one loading *all* the files; i.e., /usr and /var are both mounted by the time the early script is run). > > I don't see why the READAHEAD_EXTRA_COLLECT feature should be allowed > to block the runlevel transition, I would not call it transition, as it is executed on "end" runlevels (i.e. 2, 3, 4, 5). > rendering the machine unusable for > 10s by default (unless the user chose to run [gkwx]dm). The feature > per se is useful (let's say to include a typical console login and > startx), but it should daemonize itself instead of blocking. That's of course right. > Given that > stop-readahead-fedora depends on $all it may also arbitrarily delay > other scripts that depend on $all and happen to be sorted lexico- > graphically later (unless concurrent booting is enabled). > Indeed, although concurrent boot should become the default at some point. > [1] Apropos, wouldn't it make sense to conflict with readahead? > Ok, it's not technically necessary and having both installed doesn't > really break things, but it makes no sense either? > I've been considering adding the conflict, but I must say that it is somewhat handy not to have the conflict so that both can be installed together and compared. The more I think about it the more I'm convincing myself that I should add a conflict (breaks actually). Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
