Badblocks run time (Dreamplug + USB)

So I put my hands on two seagate external hard drives (2T), and I want to use them as a raid device. Prior using the drives, I like to run some checks on them, to see if they deserve my data to be put on them. I ran badblocks on both drives at the same time. I don't think, that it has any impact on the speed. To record how much time did it take to run badblocks on 2T drives connected through USB to my Dreamplug, I captured some outputs:

root@plugged:~# badblocks -b 1048576 -w -o badblocks.W1E2JW11 -s -v /dev/sdc
Checking for bad blocks in read-write mode
From block 0 to 1907728
Testing with pattern 0xaa: done                                
Reading and comparing: done                                
Testing with pattern 0x55:  77.39% done, 92:31:15 elapsed

root@plugged:~# badblocks -b 1048576 -w -o badblocks.W1E2GMMM -s -v /dev/sdd
Checking for bad blocks in read-write mode
From block 0 to 1907728
Testing with pattern 0xaa: done                                
Reading and comparing: done                                
Testing with pattern 0x55: done                                
Reading and comparing: done                                
Testing with pattern 0xff: done                                
Reading and comparing:   2.04% done, 172:41:55 elapsed

Badblock with these parameters tests 4 patterns: 0xaa, 0x55, 0xff, 0x00. The latter output shows the time required to get to the read-back phase of the second pattern. So let's say the read and write takes up around the same time, meaning we have the time for 5 iterations:

5x = 172
x = 34.4

And for doing all the 8 phases, you will need 275.2 hours, around 11.5 days, let's say 12 days. I am not sure, that this is the most economic way of doing it, because the drives are consuming a lot power, so it might make sense to drive them as fast as possible with a more powerful machine.

Backup Device - power save

I would like to have a backup device, to safely save down my data. I also want this solution to consume small amounts of power. Thereby, I will build it with a Raspberry PI. The problem, that I am facing, is that I don't want the hard drives to work 24/7. In order to achieve this, I need a way to power them down from my Raspberry. Options that I looked at:

• Some active circuit to power down the USB ports
• A relay based solution
• Optical controll. Dusk till Dawn adaptor in Hungary, it is called "alkonykapcsoló". Conrad sells almost the same item

This could be useful: raspberry leaf

DHCP issues with Arch on Raspberry PI

I had some issues with my Raspberry. It did not always come up after a power on. As I don't have a monitor attached to this small fruit, I was completely locked out. The applied solution was to switch to dhclient. It could be achieved by installing dhclient, and editing a profile file for that interface:

cat /etc/network.d/interfaces/eth0

DHCLIENT=yes

The small fruit seems to be happy now, and so do I.

Starting the Raspberry PI

I arrived to a point, to start my RaspberryPi, that I got for Christmas from my beautiful fiancee. Let's see: Download the image from the Arch Linux / Raspberry PI page:

wget -q http://raspberry.mythic-beasts.com/raspb
erry/images/archlinuxarm/archlinux-hf-2013-02-11/archlinux-hf-2013-02-11.zip
unzip archlinux-hf-2013-02-11.zip 

sudo dd bs=1M if=archlinux-hf-2013-02-11.img of=/dev/mmcblk0 oflag=dsync

Please note the usage of the dsync flag. Without that, I have some nasty dmesg logs, complaining:

INFO: task blkid:3812 blocked for more than 120 seconds.
...

If you want to know where dd is, send him an USR1 signal:

sudo kill -USR1 pid_of_dd

And now, plug it to the Raspberry, and see what happens! Of course, I did not plug in a keyboard, nor a screen, as I don't have such devices at home. I expect the Arch to come up nicely with an ssh server. Wow, in the DHCP, I suddenly noticed a new device, alarmpi. Okay, let's ssh in to that! The user/password is root/root Update the system:

pacman -Syu

It downloaded a new kernel as well, which is a bit scary for the first sight. I'll reboot, and see if the kernel update happened or not. The update process was really slow. I guess it is something to be done offline / in an emulator, not on the real device. The actual kernel:

Linux alarmpi 3.6.11-6-ARCH+ #1 PREEMPT Mon Feb 11 02:33:03 UTC 2013 armv6l GNU/Linux

Okay, the update finished, so I rebooted the small fruit. After that, I looked at the kernel version:

Linux alarmpi 3.6.11-8-ARCH+ #1 PREEMPT Sat Mar 9 00:38:58 UTC 2013 armv6l GNU/Linux

So it managed to successfully upgrade the kernel. Nice! Now, let's use the raspberry to check a disk for errors:

badblocks -b 1048576 -n -o badblocks.sam120 -s -v /dev/sda

Further reading for me, it might be interesting how to emulate an arm device, so that the initial update could happen on an emulator

• Interesting Post
• Look at this

Discovering rsync - TDD approach

rsyncdiscovery

A test script to find out rsync parameters for backup.

Conclusion

To copy src to tgt:

rsync -r -H -l -g -o -t -D -p --del src tgt

And you will end up with

tgt/src

being a mirror of the original src directory.

Test usage

The shell script's source and this document lives here

To discover the tests:

./test_rsync.sh list_tests

To run the tests:

sudo ./test_rsync.sh

Background

I would like to create a file-level backup of some files. My goal is to use rsync to do the job. As rsync has a lot of command line switches, first, I would need to know, which ones to use. For this, I have some expectations:

1. Backup is recursive
2. Extra files removed
3. Links are preserved
4. Symlinks are preserved
5. Symlinks are not rewritten
6. Preserve permissions
7. Modification times are preserved
8. Special files reserved

And of course, a test-driven approach will be used. Bash does not prevent you from writing tests, so go ahead.

Ending slash: The ending slash is important on the source side, if you wish to say to copy the contents of that directory, not the directory itself.

The archive mode includes:

• r - recursive
• l - copy symlinks as symlinks
• p - preserve permissions
• t - preserve modification times
• g - preserve group
• o - preserve owner
• D - preserve device and special files

And the manual also states, that it does not include:

• H - preserve hard links
• A - preserve ACLs
• X - preserve extended attributes

For me the hardlinks seem to be important.

Make an md array writable

I usually set my arrays to readoly, after assembling them. This way I could avoid unattended rebuilds. But sometimes, you would want to update some data on the disk. For doing this, let's see what we have:

root@plugged:~# mdadm --detail /dev/md1 | grep Update 

    Update Time : Sun Dec  2 12:58:58 2012

And what is the short info?

root@plugged:~# cat /proc/mdstat 

Personalities : [raid1] 
md1 : active (read-only) raid1 sdc2[0] sdd2[1]
      83884984 blocks super 1.2 [2/2] [UU]

Now, let's put it into r/w mode:

mdadm --readwrite /dev/md1

Let's see what happened:

cat /proc/mdstat

md1 : active raid1 sdc2[0] sdd2[1]
      83884984 blocks super 1.2 [2/2] [UU]

Did the superblock date changed?

root@plugged:~# mdadm --detail /dev/md1 | grep Update

    Update Time : Sun Mar 10 18:23:18 2013

So, it changed as soon, as I set it to readwrite mode.

Meet with buildroot - Custom Linux

I was thinking about having a really small linux system for cloud images. I already knew about the concept of JeOS (Just enough OS), but I still can't agree having more than 100MB as a disk. Actually, I would like to be able to have something around 50 MB. I knew about CirrOS, which we use for functional testing OpenStack. CirrOS is small, the qcow image is 10 Megs. So I looked at the launchpad site, and discovered, that cirros is using buildroot to create the root filesystem. That was enough inspiration for me to try to create a very minimal Linux. First build

$ mkdir myl
$ cd myl
$ wget -qO - http://buildroot.uclibc.org/downloads/buildroot-2013.02.tar.gz | tar -xzf -
$ cd buildroot*
$ make qemu_x86_defconfig
$ time make

Before starting make, I looked into the configuration, and it turned out, that qemu_x86_defconfig includes building a kernel, so I expect the build to last at least for an hour. In the meanwhile, it makes sense to read how I will start the machine:

$ cat board/qemu/x86/readme.txt

In the end, it was quicker than I expected:

real 26m5.626s
user 32m15.753s
sys  3m55.447s

And, let's see how it boots!

qemu-system-i386 -M pc \
-kernel output/images/bzImage \
-drive file=output/images/rootfs.ext2,if=ide \
-append root=/dev/sda

Wow! that was fast. To get a feeling on how fast it is, see this video And you might be interested in the size of the whole stuff:

$ du -shc output/images/

3.2M output/images/
3.2M total