IDEA: Shortening boot-time

[Shahms King]

On Fri, 2004-07-23 at 21:48 +0200, David Nielsen wrote:
> There's no need to mock a 10% speed up, unless there are serious issues
> with it I think 10% is worth it.
> 
> - David
> 
> On fre, 2004-07-23 at 15:28 -0400, Matthew Miller wrote:
> > On Fri, Jul 23, 2004 at 03:16:50PM -0400, Bill Nottingham wrote:
> > > The last time this was tried, the total speedup was on the order of
> > > 10% or so. Perhaps it's changed, but it wasn't a extreme speedup.
> > 
> > Yeah, I remember that. But hey, I'll take 10%. And it's probably somewhat
> > more on SMP and hyperthreading system.
> > 
> > And really, speedup and parallelization is only an incidental benefit --
> > it'd be nice for services to know what they need before they start, rather
> > than depending on magic number ordering.
> > 
> > -- 
> > Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
> > Boston University Linux      ------>                <http://linux.bu.edu/>
> > 
> > 

I took a look at this myself a little while ago and I don't think the
speedup was even that dramatic for simply running the current boot
scripts in parallel.  Admittedly, my implementation was a little
lacking, but even adding complete dependency information to the current
boot scripts probably wouldn't have a very dramatic impact.  There are
an unfortunately large number of implicit and transient dependencies on
the network being up and that is often the slowest part of the boot
process.  Even X can have such a dependency if you've configured any
XDMCP logins.  Other implicit network dependencies involve anything that
might have a file on an NFS (or other network filesystem) mounted drive
and there is no way of determining that kind of information from the
boot scripts at the moment. Some network daemons don't actually do
anything without the network but don't strictly depend on it being
available.

All of the problems are probably solvable, but there are a lot more of
them than it appears at first glance.

-- 
Shahms E. King <shahms at shahms.com>
Multnomah ESD

Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA  AB1B FEAB 3636 45B2 D75B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040723/6d01761c/attachment-0002.bin