[PC-BSD Testing] Patch to test fast-booting
tigersharke at gmail.com
Tue Dec 20 04:47:39 PST 2011
On Tue, Dec 20, 2011 at 6:32 AM, Lars Engels <lars.engels at 0x20.net> wrote:
> On Mon, Dec 19, 2011 at 01:39:26PM -0500, Kris Moore wrote:
> > Testers,
> > Got a few files here I thought I'd make available for testing to
> > evaluate putting them into 9.0.
> > This updated /etc/rc & /etc/rc.delay files change how booting works, to
> > try and boot us faster to a GUI login. This happens by delaying certain
> > services / networking from loading until after the GUI starts. On my
> > slower netboot here, it shaved a 84 second boot down to 45ish seconds,
> > almost a 50% reduction. I'll be curious to hear about others results,
> > plus if any problems occur.
> > To test this out, first as root do:
> > # cp /etc/rc /etc/rc.orig
> > Then copy the attached rc & rc.delay to /etc/rc and /etc/rc.delay
> > respectively.
> > After that you can reboot and see if it makes any difference for you.
> > If you want to undo the patch, just do:
> > # cp /etc/rc.orig /etc/rc
> > # rm /etc/rc.delay
> > I'd be curious to hear about boot-times before and after, I timed it
> > here from the boot-splash screen to the time the login appeared for GDM.
> > Thanks!
> I'd vote against adding it to 9.0. PCBSD is already in the last RC stage
> and adding this feature may be nice but can cause breakage for many
> Personally I'd love to have a faster booting FreeBSD with parallelized
> deterministic hardware sensing and parallelized rc scripts.
> But I always disliked the way Windows does it: Having a login prompt and
> desktop very early but then wait for the network... IMHO network
> connectivity should always be the first thing to start because I don't
> want an offline machine. :)
> Testing mailing list
> Testing at lists.pcbsd.org
I have not taken the time to test this. However, it seems like a reasonable
addition as a mechanism that would allow for the configuration of the
delayed loading of things. If inclusion would delay v9.0 final, then make
it available by other ways.. possibly after more testing if other edge
cases rear their ugly heads.
Lars does make a valid point, if it were to be enabled by default there are
likely to be complaints that the configuration chosen would not match the
desires of any number of users.
I definitely like the certainty of having network access right away, but if
I ran other things such as a bittorrent server/client, or other various
things that would delay my own access to the desktop (or its immediate
responsiveness), then assuming there were no other detriments, I'd like to
be able to delay those types of things.
Thanks for your hard work!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Testing