You can run, but you can’t hide from the cloud

Excited about my new Android based phone, I wanted to get it setup with my address book.

Now, one of my criteria for a cell phone is to be able to sync my contact information with a computer.  My Nokia 6585 supported irDA and could sync with my thinkpad.  When I replaced that phone with the Nokia 5310 I was able to sync over bluetooth.  Now I need to figure out how to get the data to and from my G1.

By default, the answer with an Android handset is to use Gmail Contacts.  Android is setup to guide you down the path of full Google integration, even asking you to setup the association during the phones initial setup.  Initially I wanted to avoid this route as I run my own mail server and prefer to keep my data on servers that I own (its a hobby, I know its the hard path).  I figured it couldn’t be that hard to sync the phone to my Ubuntu desktop.

One solution that looked possible was Funabol. I may still play with this, but before I even got to the point of setting up a synchronization server I ran into the problem of moving my address book data from Windows to Linux.  The Nokia PC Suite let me store all of my contacts into the Windows Address Book, and iTunes could also sync with this so my contacts were all on my iTouch.  It should be a simple thing to take the Windows Address book and move it into Linux right?

There were two problems.

  1. Windows Address book has a death grip on your data and won’t export it into a useful format.
  2. Linux has no reasonable address book story, Evolution seems to be close – but it won’t easily import anything that Windows will export.

The solution turned out to be Google. iTunes will happily sync to Google contacts.  Evolution will also sync to Google contacts.
Setting up iTunes with your Google account is straight-forward.  You just choose Google Contacts, punch in your credentials and away you go.  As my iPod Touch had lots of contact information and my Gmail account had very little, the large scale change was detected – and I was given the choice to over-write or merge (I wanted to merge).  Once the data was in Gmail, going into the Settings on the G1 and configuring the Data synchronization for Contact information let the bits flow down to my new phone.

It turns out Google has the best Linux friendly address book, better than any of the stand-alone solutions I looked at. Today the cloud won.

How to: resize a mirrored volume

Having recently setup mirrored volumes with a pair of 1TB drives, I could now migrate data off the pair of 250Gb data drives to allow me to combine those two drives into a single volume.  Way back when I purchased these drives I had intended to run a mirrored setup, but at the time decided that having more storage was more important.  I had “cleverly” purchased two 250Gb drives from different manufacturers, in theory to avoid concurrent failures.  It turns out that not all 250Gb drives are made the same.

Following the instructions from my previous posting, all went well up to where I tried to add the 2nd volume to the mirrored set.  If you run into a similar problem you’ll likely see one of the two following errors:

mdadm: add new device failed for /dev/hda1 as 2: No space left on device
mdadm: add new device failed for /dev/hda1 as 2: Invalid argument

I found some good hints on how to diagnose the problem, it turns out you can check the partition sizes manually

$ cat /proc/partitions
major minor  #blocks  name

8    17  244196001 sdb1
8    65  244198552 sde1

Close, but not quite the same.  As it was, I had unluckily chosen /dev/sdb as the 1st drive in the mirrored set.  It turns out that fdisk tells an even more interesting story.

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 250.0 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x000c0f4f

Device Boot Start End Blocks Id System
/dev/sdb1 1 30401 244196001 83 Linux

$ sudo fdisk -l /dev/sde

Disk /dev/sde: 250.0 GB, 250059350016 bytes
16 heads, 63 sectors/track, 484521 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x00000000

Device Boot Start End Blocks Id System
/dev/sde1 1 484521 244198552+ 83 Linux

Yuck, looks messy. At this point I’ve got some of my live data sitting on one half of the mirrored set, and no suitable 2nd drive to act as the mirror.  Somewhat predictably there is a solution that minimizes downtime and avoids copying all of the data to a new location.

First you unmount the volume and run resize2fs on it.  We don’t need to know the correct size, just any size smaller than the 2nd volume – so I used 200Gb.

$ sudo umount /media/data/
$ sudo e2fsck -f /dev/md2
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 1890279/15269888 files (0.2% non-contiguous), 32742192/61049616 blocks
$ sudo resize2fs /dev/md2 200G
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/md2 to 52428800 (4k) blocks.
The filesystem on /dev/md2 is now 52428800 blocks long.

Now we need to calculate what the correct size of the mirrored partition should be. I looked at two bits of data: the size the mdadm -D reported for the partition I wanted to resize, and the size that was in /proc/partitions for the same. These differed by 88 blocks, so I used the value 88 as a fudge factor – it may not be required but it worked for me. I then also ensured that I supplied a value that was an even multiple of 64 (blocks).

So starting with 244196001 from /proc/partitions:

(244196001 - 88) / 64 = 3815561.14

Drop the decimal places and multiply by 64 to get the number of blocks.

3815561 * 64 = 244195904

Now we feed this new size into mdadm and specify the –grow flag (which can also be used to shrink if you specify a block size smaller than the current which is what we are doing in this case).  We then re-run resize2fs without a specified size, which will cause it to expand the filesystem to fill the partition.

$ sudo mdadm --grow /dev/md2 --size=244195904
$ sudo resize2fs /dev/md2
resize2fs 1.40.8 (13-Mar-2008)
Resizing the filesystem on /dev/md2 to 61048976 (4k) blocks.
The filesystem on /dev/md2 is now 61048976 blocks long.

Now all that is left is to run a filesystem check, and remount it.

$sudo e2fsck -f /dev/md2
e2fsck 1.40.8 (13-Mar-2008)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/md2: 1890279/15269888 files (0.2% non-contiguous), 32742192/61048976 blocks
$ sudo mount -a

Now when you attempt to add the 2nd volume, it will be a matching size and the mirror will work.  In the future, I intend to be a little more careful when I plan to setup mirrored drives and pick the smaller volume as the starting point.

Earth Hour

The idea of Earth Hour might seem a little gimmicky due to the media attention, but it is an effective demonstration that little things add up and can make a big difference. The 8:30-9:30 pm timeslot wasn’t going to work with our kids who needed to be in bed well before then, so we decided to observe the hour from 6:30-7:30pm (you should see us on New Years eve, doing the count down at 9pm!).

At the top of this posting is a graph from the TED 5000 over the time period.  The red line is voltage, which ideally would be a flat line at 120v.  Today it seems the voltage varied from 121v to 123v.  The blue line is the power in kW being consumed.  Today was a laundry day (seems to always  be laundry day lately) and while we have energy efficient appliances, the dryer still eats a lot of watts.

So after dinner, we took a reading using the Ted-O-Meter on the iTouch we saw that our consumption was around 1.9kW.  On the graph this would be roughly above the word “Data” in the “Real-Time Minute Data”. We then went around the house turning off lights, and powering down stuff that didn’t need to be on (computers, PVRs, etc).  On the list of non-essential items were the stereo, pretty much anything with a wall wart, and night-lights too. When we looked again we had dropped down to 0.9kW.  After that it was bedtime for the kids, and we left things “dark” until 10pm when it was time to start up the dryer again and do a few things before going to sleep.  (Ok, I was sitting in the dark surfing on my new G1)

The TED 5000 combined with the Ted-O-Meter is a great way to bring awareness to you and your family about changing little things to make a difference.  To be able to turn off the lights in a room, and see the needle drop is very motivating.  You can see from the screen capture on the right that we managed to hit a consumption low of 0.770kW at 7:15pm today.

The computer industry has embraced “green” as there is a direct correlation between energy costs (primarily cooling) and profit. We’re not quite there for the home, but I suspect it will come once more people can easily measure their usage and effect change.