We are constantly measuring boot time for Solaris builds, too. We would consider it a regression if boot times increase. Interestingly, on one of my test machines at home, I can get to a login prompt on Solaris 10 in about 12-13 seconds... -- richard

Posted by Richard Elling on December 05, 2004 at 09:50 AM PST #

I find Solaris installs to be much slower than Fedora installs on the same hardware. Maybe the install needs some D loving.

Wanted to also point out 2 blog posts which describe a Solaris 10 install from a Linux user (This is similar to what I felt when I installed b69)

Solaris installation Part 1

Solaris installation Part 2

Posted by Yusuf Goolamabbas on December 05, 2004 at 06:22 PM PST #

XP does some tricks to speed up disk. First. it tracks the information about what portions of the disk are used when booting, or when a app starts up. With that information in place, it "preloads" all the neccesary data from disk to memory. Doing this. you can fetch all the needed data with a few reads instead of pagefaulting or reading files with small reads, and this speeds up the boot. Also, the defragmenter analizes all that information and places the programs which are used more often in the places of the disk where the can be loaded faster. In fact, the defragmenter starts up automatically ever three days and does all this in the background if the box is idle, without you noticing it. I know we hate defragmenters in the unix world, but the above example shows that a defragmentation API is not a bad idea at all. Solaris and linux kernels can keep a file unfragmented, but they don't (can't) know what programs are used more often. XP may not be our preffered OS but in the desktop field is ahead of us (not for long time, I hope) Mac OS X uses similar tricks, if you're curious you can look at the Darwin sources, it's all there! I'm afraid that all the optimizations you do with scripts startup et all. won't be enought, they'll be faster but I doubt they're the real fix for the problem. We need something like the XP/mac os x "preloaders", IMHO. I've also though about things like "process freezing" (pause a process and store its image on disk and stop it, then awake it when you want) that could help greatly for desktops. If we could store on disk the process imagen of ej: evolution, and restore it when you switch on your computer again, 1) it'd be faster (no startup costs) and 2) and more important: you'd get a evolution which is in the SAME than when you switched off the computer.

Posted by Diego on December 06, 2004 at 07:53 AM PST #

Recent efforts with Fedora Core 3 - parallelizing modprobes, not inserting floppy driver on a floppyless machine, ditching rhgb and readahead_early of all of the KDE/Qt libraries have resulted in pretty acceptable boot times. Tracking the page faults to predict the usage and then prefetching them should yield boot times comparable with XP - but I would much rather have suspend and swsup working - who needs to reboot it anyways?

Posted by YetAnotherName on December 06, 2004 at 12:23 PM PST #

Booting an ultra 5 off of solaris 10 CDs (as the first step to installing it) is a painfully length process. From the sounds of the CD, reads are jumping all over the place. Isn't there some way to preread in to memory most of the data in one pass from the CD, rather than relying on the normal paging mechanism? This would be a lot faster. And I wonder if it would give any improvements in the usual boot from hard disk case?

Posted by Todd Olson on December 15, 2004 at 11:42 AM PST #