Setting up SAIL for diskless running

About the -447 Release

SAIL-447 was built specifically to run in diskless environments, however it will also run happily in conventional environments where it can, under certain conditions, add a significant performance boost to the platform. All versions of SAIL since -447 have the capability to run in solid state environments.

Like other embedded implementations, SAIL works by holding its working program set and its volatile files in main memory. Unlike other embedded implementations, a full-dress SAIL install is big. For this reason it needs a fair amount of resource, at least 512Mb of main memory and a 4Gb Compact Flash Card. Fortunately, these things are now ridiculously cheap so you can build a solid state system for about the same as a disk-based equivalent or you can simply use the SAIL memory management to give a speed-boost to your conventional system.

One other requirement is that SAIL will only run with "true" i686 CPU's so, for the moment, many of the low-end/single board CPU's won't work. All of our testing was done with VIA C7 "Nehemiah" chips and we can report that they work very well indeed, with significant observed performance gains over similar "disk based" systems using the same chipset.

Installation

On regular disk-based systems, installation of SAIL-447 is no different to any other SAIL release. Simply follow the installation instructions in the 2.1.14 Stable Quicknotes guide.

Compact Flash Install

Obviously, in order to install SAIL in a CFCard environment, you must first install a complete SME-Server onto the card. This is easier than it might seem. First of all, you will need an ordinary CF to IDE converter and a 2Gig Compact Flash Card. These plug into any free IDE slot on your mother board, either directly or via a conventional IDE ribbon cable. Items can be purchased on the internet for just a few Euros or Dollars. At time of writing, a 2Gb high-speed CF Card can be purchased in the UK for around £20 (32 Euro). This is just big enough to hold the SME/SAIL image.

Install your CF Card and then install SME Server 7.1 from CD in the normal way. Your mileage may vary during this exercise. We have tried several motherboards that simply will not do the install, others work fine and we have no idea why.

The installation is slow, the installer will spend a lot of time attempting to treat the CF Card as a regular DMA disk. However, be patient, it will eventually figure out that it is dealing with a device that won't support DMA and switch it off. Thereafter the install is conventional but slow compared to a normal disk install.

At the first reboot (after the initial install has finished and the installer prompts you to remove the install CD), press the spacebar at the penguin splash screen. Choose the UP kernel (NOT the SMP kernel) and the press "a" to modify the grub load statement.

Type a space followed by ide=nodma and hit return. This will stop the system from attempting to treat the CF Card as if it is DMA capable and will greatly speed up the boot process.

Finish the install in the normal way. You now should have a complete SME Server system running from flash.

Unfortunately, left to its own devices, this is likely to be a short-lived system. While Compact Flash has many advantages over conventional disk drives (low power consumption, vitually zero heat output, capable of withstanding very high acceleration/deceleration) it has one major drawback; it can only stand around 1 million writes. After that it will fail. One million writes sounds like a lot but in a busy server environment it's nothing at all, perhaps three or four month's running time. For this reason, embedded systems attempt to keep their CF Card writes to a minimum by holding volatile files either in memory or on a separate medium, for example a cheap, replaceable USB memory stick (about 10 bucks for a 256Meg item). As we shall see in the next section, SAIL-447 can do both.

How SAIL manages memory

Outwardly, SAIL-447 looks very little different to its predecessors and in fact there is only one new control (and two new buttons) which you will find on the Globals panel.

The new control is called logging options. It has three possible settings; native, ramdisk and usbstick. By default, the system will come up under the native setting. In order to actuate a change you just change the value in globals and then reboot the system for it to take effect.

Native option

Under the covers, SAIL-447 makes a lot of changes to the underlying operating system. 447 includes a new server component called ramdisk. This server starts very soon after the system enters run-level 7 ( before the system and kerenl loggers have started). It first checks to see if the system is running from Compact Flash. If it is, the server modifies fstab "on the fly" to turn off ATIME on /dev/root and then disables swap space. What happens after that depends upon what the "logging options" control is set to. If it is native then ramdisk will exit and the system will run pretty much as it does conventionally (although without swap). If it is set to ramdisk or usbstick, the ramdisk server will do the necessary work to "fool" sme-server into believing that it is still running normally while, under the covers, redirecting reads and writes to memory or the USB Stick. Mechanically, this is achieved using conventional symlink and overmount techniques, very similar to AstLinux. The advantage of this is that it should always fail to a restartable condition (at least, that's the theory).

Ramdisk option

This is something of a misnomer because SAIL doesn't use ramdisks. Instead, it uses tmpfs which is faster, simpler and has the added advantage of dynamic expansion and contraction as needed ( and it was designed by Linus himself). When SAIL enters ramdisk mode it loads all logfiles and many volatile files (such as /tmp) into main memory. In order to conserve space, it also changes your logging options "on the fly" so that logrotate runs more frequently and fewer generations (backups) are kept. Once up and running in this mode you should see virtually no I/O to the flash disk. Your disk light should only come on when new programs are being loaded, for example when server-manager is running. Asterisk should run without a flicker. This means that, hopefully, we should get long and reliable service from our flash card. You should also remeber to dump your logfiles to a spare USB stick using the new "Dump" button (in Globals). By the way, the fact that you can't see the dump button is normal... It will only appear when you insert a USB Drive.

N.B. you should keep an eye on available memory in a ramdisk scenario because there is no swap to absorb any overflow. For this reason, all of the necessary metrics (memory usage etc etc) are now displayed on the Globals panel. You should also consider turning of unused servers - for example, we don't run clam on our PBX server.

USBStick option

In order for SAIL to use USB for it's logs and volatile files, the USB stick must be formatted as an ext2 filesystem (however, you can use a regular FAT or VFAT stick for the PBX personality dump/restore feature). Under startup, if usbstick is specified, the ramdisk server will check for the presence of a USB device and if found, ensure that it contains an ext2 file system. If either of these things are missing or untrue, ramdisk will ignore the usbstick setting and bring the system up in native mode.

Where next?

We'll keep updating this howto over the next few weeks and months as we learn more about -447's behaviour. In particular we would like to allow you to use RAM and USB space at the same time and to choose which volatile elements go where. The file names are kept in the Selintra database so it's relatively easy to change what gets shunted around the place and what doesn't, however there are a few corner cases that we need to figure out before we open these mechanics up. The problems tendto arrive when you change from one state to another. We'd also like to be able to change state in real time without the current need to restart the system.

Formatting your USB Stick as ext2 and creating a Filesystem on it.

Shove your USB stick into the USB slot but don't mount it. Now do...

fdisk /dev/sda
Command (m for help):d {press enter }
Selected partition 1
Command (m for help):n {press enter}
Command action
e extended
p primary partition (1-4)
p {enter}
Partition number (1-4):1 {press enter}
First cylinder (1-888, default 1): {press enter}
Using default value 1
Last cylinder ... (1-888, default 888): {press enter}
Using default value 888
Command (m for help):w {press enter}

mke2fs /dev/sda1 {press enter}

Er.. That's it, you should now be able to mount your drive.

SME Server manager viewlogs panel

You will notice that the viewlogs panel runs slightly differently when the system is in ramdisk or usbstick mode. This is because the traditional item uses a Perl treewalk routine which is unable to follow symlinks so we needed a new program to handle them. The new item has a tree walker that can recursively restart itself whenever it encounters a link.

The 2 "viewlogs" programs are dynamically "swapped" in and out of functions (the directory where server-manager programs are kept) when needed, by the ramdisk server. This has the advantage of our RPMS not interfering with the stock SME Server stuff. Unfortunately, we didn't quite get the display right for this release so you will notice a difference.