Tonights session started out with a brain storming session to capture information about the river users, their needs and known issues. It then turned into a discussion session looking at how to reach out to the wider community of river users.

I didn’t take note of everyone who was there but there were a few of us from the rowing community; Durham University Sport; River Wears Trust; Angling community along with a few others.

Side note: Even though I have lived in Durham for approaching 20 years this was the first time that I’ve visited Alington House. I’ve heard lots about it in the press but never been there. Whilst its an old building it does have a nice view overlooking the river.

The transfer of the data went pretty painlessly. Mostly thanks to the flexibility of Linux for booting and good old Knoppix to allow me to easily boot from the new drive and reinstall the boot sector.

Drive Caddy Woes

I have a small drive caddy that takes 2.5 inch drives and allows them to be used as external drives. My original intention was to install the new drive in that and then use Knoppix booted from DVD to copy the contents of my existing drive to the new drive.

Within a few seconds I realised that the caddy used an IDE based drive connnector so it wouldn’t take a SATA connected drive that my laptop needs. After a few minutes searching I realised that I would have to use a desktop PC and connect both drives to that. Of course the PC only had 2 SATA connections so that meant that I didn’t have a spare connection to attach the DVD drive to boot from.

Live Data Migration

No problem! Just boot from the old drive and perform a “live” data migration to the new drive.

Running in single user mode all of the non-root partitions were unmounted to minimise the risk of filesystem corruption. The root drive had to stay mounted. In theory it would have been possible to mount it readonly but I just left it mounted read-write and made sure that it was fsck’d (filesystem consistency checked) after the migration.

Partition Table

First step in transferring the data is to ensure that the new drive has a partition table that matches that of the old drive.

Previous drive migrations have been easy but the new drive has a physical sector size of 4096 bytes whereas the previous drive used 512 bytes. This means that the exact location of each sector needs to be aligned and tweaked. The important thing is that each partition needs to at least as big as the original partition on the old drive. The additional disk space left over was added as a large LVM partion.

The other important thing is that the number of each partition is maintained. In theory this is not essential but it does make life easier.

The new partition table is as follows

richard@laptop:~$ sudo fdisk /dev/sda
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Command (m for help): p
Disk /dev/sda: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000009ec
Device Boot Start End Blocks Id System
/dev/sda1 2048 229375 113664 de Dell Utility
/dev/sda2 229376 6526855 3148740 b W95 FAT32
/dev/sda3 6526856 48488635 20980890 83 Linux
/dev/sda4 48490496 1465149167 708329336 5 Extended
/dev/sda5 48492544 476512275 214009866 8e Linux LVM
/dev/sda6 476516352 488404991 5944320 82 Linux swap / Solaris
/dev/sda7 488407040 1465149167 488371064 8e Linux LVM

Transferring Data

With the partitions correctly configured the data from each partition needs transferring over to the new drive. The dd command does this with ease but do remember to specify a large block size to make transfer more efficient. I also stopped my LVM volumes using vgchange to minimise chances of corruption in those volumes.

vgchange -an
dd if=/dev/sda1 of=/dev/sdb1 bs=64M
dd if=/dev/sda2 of=/dev/sdb2 bs=64M
dd if=/dev/sda3 of=/dev/sdb3 bs=64M
dd if=/dev/sda5 of=/dev/sdb5 bs=64M
dd if=/dev/sda6 of=/dev/sdb6 bs=64M

Without bs specified the transfer is inefficient. Indeed with the default blocksize writes become very inefficient because the target drive has to read the data before writing because only small fragments of a sector are written at once. You can see this in the output of the iostat 5 sda command.

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 5386.80 21376.00 21038.40 106880 105192

the kB_read and kB_wrtn values are approximately equal using the default blocksize in dd. But when using a larger blocksize reads do not occur.

Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 191.00 0.00 96980.00 0 484900

After copying (which may take a number of hours) then it is advisable to consistency check each partition. In my case I just checked the root partition that was copied whilst mounted read-write using

fsck -f -y /dev/sda3

Making it all bootable

After transferring the data the boot sector needs writing to the new drive. To do this the transfer PC was power down and the new drive installed into the laptop.

The laptop was now booted from a Knoppix DVD using the grub option which causes it to find a bootable partition on the disc and to use that as the root partition. Once booted the boot sector can be installed using grub-install

grub-install /dev/sda

At this stage you should be able to reboot the laptop from the new drive.

Using the additional space

Finally the new space can be added to the LVM pool using

pvcreate /dev/sda7
pvextend mygroup /dev/sda7

where mygroup is the name of the LVM volume group.

At this point the additional space can be added to a volume group using the usual LVM commands.

Today I received an email from Farnell stating that they are taking orders in batches with delivery scheduled in about 30 days. Needless to say I’ve placed an order and it seems we get a free -tshirt thrown in too. Can’t wait!

Peter made a huge contribution to rowing in our region as a competitor, coach, volunteer and supporter. His picture appears on many photos on the walls of the Durham ARC Boathouse spanning over many decades. He has been particularly effective in bringing newcomers into rowing.

In 2011 Peter was awarded the British Rowing Volunteer of the Year Award and this is a most fitting way to remember his contribution to our sport.

Update: British Rowing have an article on Peter and I’m told that there will be an article about Peter in the next edition of Rowing & Regatta magazine.

In the past week I have been looking to add SPF records for a few domains that send/receive mail via my hosting provider Mythic Beasts. I was concerned about ensuring that the SPF records stay in sync with any future server changes at Mythic Beasts. When asked the Mythic Beasts guys informed me that they hadn’t been asked about this before but they quickly got their thinking hats on and came up with an SPF record at _spf.mythic-beasts.com

richm@royalcounty:~$ host -t spf _spf.mythic-beasts.com
_spf.mythic-beasts.com has SPF record "v=spf1 ip4:93.93.130.6 ip4:93.93.131.52 ip4:93.93.131.30 ip4:93.93.131.127 ip4:93.93.130.44 ip6:2a00:1098:0:86:1000::10/127 -all"

Now all I need to do is to add a an SPF record that references _spf.mythic-beasts.com using an include: clause and it will automatically pick up the changes made by Mythic Beasts without me having to change anything.

richm@royalcounty:~$ host -t  spf oldelvet.org.uk
oldelvet.org.uk has SPF record “v=spf1 include:_spf.mythic-beasts.com -all”

It is possible to use multiple include: clauses in one SPF record so if you send mail from more than one hosting provider/ISP you can easily do that.

So far things seem to be working fairly well. I did spot one initial problem where we used include= instead of include: and this meant that the correct record was not included.

I also noticed that on my existing records I was using square braces around ip6 addresses.

ip6:[2a00:1098:0:80:1000:4:1010:1010]

I’m not sure where this came from but it did seem to work but does not look to be part of the standard. I’ve now removed that.

ip6:2a00:1098:0:80:1000:4:1010:1010

For now I have left the revised SPF records with short time-to-live (TTL) times so that I can make changes quickly if I spot any further problems.

That made me wonder if the imminent arrival of IPv6 enabled servers/sites could introduce a vulerability here because IPv6 often uses the MAC address to generate a unique link local (and in some cases global) IPv6 address.

Food for thought…

Some key points of the documentary include:

• The Sexton Beetles that burried a dead rat within a couple of hours to use as food/housing for their offspring.
• The single celled mould/jelly that was able to build a near optimal network of paths between sources of food placed in the environment. Good to see that this is being investigated by Computer Scientists to see what lessons can be learned for planning/problem solving applications.
• The Fly Trap where many of the flies in the environment had unexpectedly ended up in a bottle of wine.