On Thu, Apr 02, 2009 at 02:34:36PM +0530, Arun Raghavan wrote:
> 2009/4/2 Vladimir Skuratovich <skuratovich@...>:
> > wait in the session manager for it to be mounted, while X is
> > starting up? Not sure what to do with other filesystems, such ...
>
> This would need changes to the session manager, right? Is that really
> something that we want to be doing?
It depends on whether we just want a system that boots faster, or one
that boots as fast as possible. And if we have such a system, we could
offer a range of configuration options between "reliably boots on
every imaginable configuration" and "boots very fast, but only on the
specific machine it was installed".
> > - Gentoo init scripts perform a lot of 'autodetection' of different
> > system parameters. Probably the autodetection could be left as a
> > 'safe boot' option, and the real values could be recorded somewhere
> > and loaded at boot time?
>
> You'd need to add some quick sanity check for things like moving
> hard-disks across hardware.
I meant parameters like kernel version, presence of specific
filesystems in the kernel and so on. They can change during kernel
upgrades, for example, but then the first time the system could be
started in a 'less aggressive' mode, while recording the parameters
for the following boots.
Of course, checking whether the drive is installed in the same machine
could also be useful - that would mean, for example, that the static
device nodes should not be used.
>
> > - Instead of cleaning directories such as /var/run, they can be
> > mounted on tmpfs and the necessary directory tree inside can be
> > recreated every time.
>
> Might there be cases where these files would be needed to analyse
> crashes or for forensics?
There might, but on my system, for example, there are only pidfiles
and sockets in /var/run, and only a couple of potentially useful files
in /tmp.
>
> > - Placing static device nodes on /dev while udev is starting speeds up
> > the boot significantly for me
>
> By how much?
According to the boot chart it takes about 2 seconds for 'udevadm
trigger' to execute - that means a lot of processes can use the static
nodes while udev is creating the dynamic ones.
> What kind of impact is dm-crypt having on your numbers?
I don't know, as I have only a small /boot partition not on
dm-crypt. I don't think the impact will be significant on today's
hardware - probably about an additional second or so.
Finding the exact numbers would require me to back up everything and
reformat the whole hard drive.
> Would be nice to look at, IMO. If you need it to be hosted somewhere,
> mail them to me and I'll put them up.
I've just sent them to you.
> I'm a little confused here. What system were these tests run on?
The tests were run on a LFS system (with glibc 2.9, compiled with GCC
4.3.2 with optimizations, kernel 2.6.29 with a lot of patches).
The file system for both / and /home is reiser4 with cryptcompress
plugin (gzip compression - probably it could also impact performance?)
The system uses initng, but it seems very similar to OpenRC in its boot
script format.
Regards,
Vladimir
|