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.

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