Following on from our earlier article about upgrading from a traditional hard disk to an SSD, we tested that old metric, boot time.

We used the excellent bootchart tool to gather these statistics. It's worth noting that time for the BIOS to post takes quite a long time (about another 30 seconds). We are only timing from kernel load to end of startup.

Overview

In this blog post we'll be covering setting up an SSD for Linux and then sharing the results of some performance testing.

What is an SSD?

SSDs are now well established as high performance alternatives to hard disks. Rather than using a spinning, magnetised disk and a tiny read/write head on the end of an arm, they are more like memory chips - completely "Solid State" Disks (no moving parts).

For some time now we've used PXElinux from the fabulous Syslinux project to netboot servers when we automatically install them. When we restart a machine this now provides us with the following menu:

Virtualisation has gone through four main phases:

• full software emulation - every instruction is emulated - very, very slow. (Bochs)
• software virtualisation - instructions are checked but most run natively. (VMWare server)
• paravirtualisation - the guest operating systems know they are virtualised and are tweaked appropriately (Xen)
• hardware assisted virtualisation - the CPU provides assistance to the above methods (KVM)

The programs above are only very roughly categorised, for example virtio provides paravirtualisation to KVM.

One of our puppet rules ensures that NTP (which ensures that the server has the correct time) is not installed on any virtualised guest images where the time is supposed to be taken from the host automatically. Unfortunately "facter" which should provide this information still hasn't applied patches submitted over 6 months ago. So we've rolled our own package instead for use on Debian Lenny.

Overview

Sometimes it's useful to have a console permanently logged in. That is without the usual username/password prompt. Naturally you are relying on just physical security here.

Howto

Edit /etc/inittab and find the lines like this:

3:23:respawn:/sbin/getty 38400 tty3


Change these to:

3:23:respawn:/sbin/getty -n -l /usr/local/bin/autologin 38400 tty3


Finally run

telinit q


That's it, nice and simple. Just ensure that you have a unique ID (the part before the first colon) and you've specified the correct terminal at the end.

When creating virtual disks for KVM you can use several methods. Most people use flat files in one of several formats - raw and qcow2 being the most popular. qcow2 files can compressed and also have "holes" (where unused space doesn't use up real space).

We recently converted some old systems from flat files to using logical volumes as it's the recommended approach these days.

If you are using raw flat files (use "qemu-img info filename.img" to find out) then you can just use "dd if=filename.img of=/dev/rootvg/logicalvolume".

As an update to the Qemu-KVM packages we now present 64-bit Debian Lenny versions for your enjoyment.

Drupal has also been updated to v6.14.

On the principle that "every little helps" you might want to consider dropbear as a replacement for OpenSSH.

This reduces VSZ/RSZ (see earlier blog post) from 5/0.5MB to 2/0.5MB on a 32 bit box, but a much more impressive 43/1MB -> 10.5/0.5MB on a 64-bit machine.

As mentioned in the earlier http://bitcube.co.uk/content/community-spirit post, contributing back is important. Attending various LUG meetings, we often hear "oh, but I'm not a coder" - normally this answer isn't from people trying to avoid helping - they genuinely believe this to be the case.