| 1 |
On Thu, Apr 02, 2009 at 02:34:36PM +0530, Arun Raghavan wrote: |
| 2 |
> 2009/4/2 Vladimir Skuratovich <skuratovich@×××××.com>: |
| 3 |
> > wait in the session manager for it to be mounted, while X is |
| 4 |
> > starting up? Not sure what to do with other filesystems, such ... |
| 5 |
> |
| 6 |
> This would need changes to the session manager, right? Is that really |
| 7 |
> something that we want to be doing? |
| 8 |
|
| 9 |
It depends on whether we just want a system that boots faster, or one |
| 10 |
that boots as fast as possible. And if we have such a system, we could |
| 11 |
offer a range of configuration options between "reliably boots on |
| 12 |
every imaginable configuration" and "boots very fast, but only on the |
| 13 |
specific machine it was installed". |
| 14 |
|
| 15 |
|
| 16 |
> > - Gentoo init scripts perform a lot of 'autodetection' of different |
| 17 |
> > system parameters. Probably the autodetection could be left as a |
| 18 |
> > 'safe boot' option, and the real values could be recorded somewhere |
| 19 |
> > and loaded at boot time? |
| 20 |
> |
| 21 |
> You'd need to add some quick sanity check for things like moving |
| 22 |
> hard-disks across hardware. |
| 23 |
|
| 24 |
I meant parameters like kernel version, presence of specific |
| 25 |
filesystems in the kernel and so on. They can change during kernel |
| 26 |
upgrades, for example, but then the first time the system could be |
| 27 |
started in a 'less aggressive' mode, while recording the parameters |
| 28 |
for the following boots. |
| 29 |
|
| 30 |
Of course, checking whether the drive is installed in the same machine |
| 31 |
could also be useful - that would mean, for example, that the static |
| 32 |
device nodes should not be used. |
| 33 |
|
| 34 |
> |
| 35 |
> > - Instead of cleaning directories such as /var/run, they can be |
| 36 |
> > mounted on tmpfs and the necessary directory tree inside can be |
| 37 |
> > recreated every time. |
| 38 |
> |
| 39 |
> Might there be cases where these files would be needed to analyse |
| 40 |
> crashes or for forensics? |
| 41 |
|
| 42 |
There might, but on my system, for example, there are only pidfiles |
| 43 |
and sockets in /var/run, and only a couple of potentially useful files |
| 44 |
in /tmp. |
| 45 |
|
| 46 |
> |
| 47 |
> > - Placing static device nodes on /dev while udev is starting speeds up |
| 48 |
> > the boot significantly for me |
| 49 |
> |
| 50 |
> By how much? |
| 51 |
|
| 52 |
According to the boot chart it takes about 2 seconds for 'udevadm |
| 53 |
trigger' to execute - that means a lot of processes can use the static |
| 54 |
nodes while udev is creating the dynamic ones. |
| 55 |
|
| 56 |
|
| 57 |
> What kind of impact is dm-crypt having on your numbers? |
| 58 |
|
| 59 |
I don't know, as I have only a small /boot partition not on |
| 60 |
dm-crypt. I don't think the impact will be significant on today's |
| 61 |
hardware - probably about an additional second or so. |
| 62 |
|
| 63 |
Finding the exact numbers would require me to back up everything and |
| 64 |
reformat the whole hard drive. |
| 65 |
|
| 66 |
> Would be nice to look at, IMO. If you need it to be hosted somewhere, |
| 67 |
> mail them to me and I'll put them up. |
| 68 |
|
| 69 |
I've just sent them to you. |
| 70 |
|
| 71 |
> I'm a little confused here. What system were these tests run on? |
| 72 |
|
| 73 |
The tests were run on a LFS system (with glibc 2.9, compiled with GCC |
| 74 |
4.3.2 with optimizations, kernel 2.6.29 with a lot of patches). |
| 75 |
The file system for both / and /home is reiser4 with cryptcompress |
| 76 |
plugin (gzip compression - probably it could also impact performance?) |
| 77 |
|
| 78 |
The system uses initng, but it seems very similar to OpenRC in its boot |
| 79 |
script format. |
| 80 |
|
| 81 |
|
| 82 |
Regards, |
| 83 |
Vladimir |
Archives