Hi, in my opinion the Grml startup is quite slow and I think we should address this issue for the next release. (iirc 45 seconds inside kvm)
One and a quite easy but also a little problematic solution would be the parallel execution of startup scripts. But afaik this is currently not possible with file-rc but upstream (Hi Mika and formormer) is somehow working on it.
The other and more easy solution would be parallelizise grml-autoconfig to some point, e.g. run all scripts parallel by just adding & to the function. Of course there have to be some exceptions like network should not be done in the background as other scripts like net{script,config} depends on it.
This could be easily done but does require carefully testing to not break some usecases, e.g. do not change the order of netconfig/netscript as they could depend on each other.
So my question is, is it worthwhile to put some effort into faster startup? What else could be done (iso/squashfs sort)? Shall we switch to dependency based booting at some point?
regards, Ulrich
On Tue, Apr 13, 2010 at 20:12, Ulrich Dangel mru@grml.org wrote:
So my question is, is it worthwhile to put some effort into faster startup? What else could be done (iso/squashfs sort)? Shall we switch to dependency based booting at some point?
Faster start-up is always better for obvious reasons. Not that I consider Grml to boot slowly, mind.
Yet, if I had to choose between slow start-up and the tiniest chance of things breaking, I know which I would choose. An optional boot parameter to fall back to the old system would make sense, imo.
Richard
* Richard Hartmann richih.mailinglist@gmail.com [Wed Apr 14, 2010 at 10:25:46AM +0200]:
On Tue, Apr 13, 2010 at 20:12, Ulrich Dangel mru@grml.org wrote:
So my question is, is it worthwhile to put some effort into faster startup? What else could be done (iso/squashfs sort)? Shall we switch to dependency based booting at some point?
Faster start-up is always better for obvious reasons. Not that I consider Grml to boot slowly, mind.
Yet, if I had to choose between slow start-up and the tiniest chance of things breaking, I know which I would choose. An optional boot parameter to fall back to the old system would make sense, imo.
FullACK.
We should tweak the squashfs part, spot ways for improved readahead and check out whether there are parts left where we could further parallelize stuff - but all without breaking anything.
regards, -mika-
On Wed, Apr 14, 2010 at 10:38, Michael Prokop mika@grml.org wrote:
spot ways for improved readahead
Putting on my pedantic hat, read-ahead means that if there is an issue reading from disk, Grml might hang while the user has been displayed irrelevant stuff. This leads to wrong bug reports.
Not saying it's not worthwhile, just something to keep in mind and a reminder to use error & warning messages aggressively.
Richard
Teilnehmer (3)
-
Michael Prokop -
Richard Hartmann -
Ulrich Dangel