This article is more than 1 year old

How I built a zero energy cost, zero carbon home server

Running an internet biz on sunshine and *nix

For all-flash storage, reducing "disc" activity to minimise power consumption is a must, and reducing write activity to maximise lifetime is also important. I also laid out the filesystems (efs3) as suggested by Theodore Ts'o to line up allocation boundaries with the likely flash block boundaries to minimise wear, as well as setting long timeouts between write flushes and avoiding noting each time a file is read (accessed) using the mount options noatime,commit=600.

For example, here is the set-up of one partition on flash media:

fdisk -H 224 -S 56 /dev/sda

To create cylinders of 49*128kB, with a small leading VFAT utility partition:

mkfs -t vfat /dev/sda1

To allow the main/second partition to be cylinder- and erase-block- aligned, then to make that labelled main ext3 partition with better-than-default sizing (no space for expansion, directory indexes, sparse superblocks, an inode per 128kB, which is a decent safety margin over the current 500kB/file usage). I ran:

mkfs -t ext3 -i 131072 -O ^resize_inod,dir_index,sparse_super /dev/sda2

I also rigged the flash thumb-drive partition to be powered up and automounted on use, and unmounted and powered down when idle to reduce the otherwise considerable power draw from USB hubs with downstream storage keeping them awake.

More worryingly, though, without any major catastrophe so far, is that the USB flash drive and ext3 combo seems occasionally to lock up, fail to write a bunch of data, and then requires some manual surgery after an fsck. Alarmingly, some files that initially seem to have been written correctly look very broken after a restart/fsck. As far as I know, I've not lost anything major, and I systematically keep checksums (and backups) of all the important files, but it's a major issue that I will need to resolve.

Embedding the Shark

On the Java front, one downside of going to ARM on the Sheeva is that the "standard" Sun-supplied Intel Linux JVM builds are not available.

I looked at the free options such as Zero/Shark on IcedTea, and I've tested various versions of it with the help of the developers, and it is getting better over time. It's certainly a good fall-back.

But Sun made available a copy of their "embedded" ARM JRE available to me (before being swallowed up by Oracle), which works pretty well. It's not a "server" VM (it could probably run a little faster if it were), and not being a full JDK I had to upgrade from Tomcat 4 to Tomcat 6 to be able to use it. It also seems that the garbage collectors other than the default serial GC are still a little buggy, causing the occasional crash, but I'm happy with it.

Note that the ARM chip in the Sheeva has no hardware floating-point support, but then floating point is pretty slow on my Niagara box too, so I'd already converted everything performance-critical to fixed point.

For me WORA (Write Once Run Anywhere) really does work, as my Java Web server runs from the same WAR file on the SheevaPlug (ARM) and on Solaris SPARC and various Linux Intel x86 mirrors.

Even with nominally enough solar PV and battery last year (more than 100Wp and 250Wh respectively, for a 4W typical consumption) I had to run the SheevaPlug on mains for most of the winter of 2009/2010. This year I've about doubled the PV and battery capacity in the hope that I can stay off-grid even in the bleak mid-winter...

The system monitors its own battery state via a k8055 USB I/O card, avoiding optional tasks (thus energy consumption) when the battery gets low, and conversely cranks my AI-based image-rating system when the sun is out and the batteries bursting at the seams.

Next page: Lessons Learned

More about

More about

More about

TIP US OFF

Send us news


Other stories you might like