human choroinic gonadotropin

GGTSdotNET

The notes of a madman

Archive for January, 2008

Sorting IP addresses

Posted by grigsby on January 17, 2008

I recently had to sort a large list of IP address numerically. My first few passes didn’t work. Finally I pieced the following together. This is using sort from the GNU coreutils, version 5.97, running on a CentOS 5.0 box. Should work on anything running GNU Sort. It might work on other versions of sort, but I had issues with it on HP-UX. This worked in a few seconds for well over 50k addresses. Enjoy.


sort -t'.' -nk 1,1 -k 2,2 -k 3,3 -k 4,4

Recovering a failed raid array

Posted by grigsby on January 8, 2008

Just had an external SCSI chassis go offline. The chassis was connected to one UPS while the computer was connected to another ( I know, I know). The UPS powering the SCSI drives went south for the winter. This mad the OS/SCSI bus all kinds of unhappy. Had to hard boot the system. When I brought the system backup it refused to start the software raid system built on the external chassis. First I checked to make sure the drives were all being seen. They were:

[root@lnxets2 root]# mdadm --examine --scan /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdf2 /dev/sdg1 /dev/sdg2
ARRAY /dev/md0 level=raid5 num-devices=7 UUID=776de615:eecea59e:e1e94c0a:c8a70e3f
devices=/dev/sdc1,/dev/sdd1,/dev/sde1,/dev/sdf1,/dev/sdf2,/dev/sdg1,/dev/sdg2

So now I try to bring the array up:

[root@lnxets2 root]# mdadm -A /dev/md0 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdf2 /dev/sdg1 /dev/sdg2
mdadm: /dev/md0 assembled from 1 drive - not enough to start the array.

Google was of no help on this. The error seemed to indicate slices were missing from the array, but the OS saw them. fdisk saw them. I then started examining the each slice, using mdadm -E /dev/sdc1, one at a time and found that all of the devices in the external array were marked faulty, most likely because they had gone offline due to the power failure. So, since the data was backed up, I decided to try to force the array back to live using the following:

[root@lnxets2 proc]# mdadm -A /dev/md0 /dev/sdc1 /dev/sdd1 /dev/sde1 /dev/sdf1 /dev/sdf2 /dev/sdg2 /dev/sdg1 /dev/sdb1 -f
mdadm: forcing event count in /dev/sdd1(1) from 7 upto 10
mdadm: forcing event count in /dev/sde1(2) from 7 upto 10
mdadm: forcing event count in /dev/sdf1(3) from 7 upto 10
mdadm: forcing event count in /dev/sdf2(4) from 7 upto 10
mdadm: forcing event count in /dev/sdg1(5) from 7 upto 10
mdadm: clearing FAULTY flag for device 1 in /dev/md0 for /dev/sdd1
mdadm: clearing FAULTY flag for device 2 in /dev/md0 for /dev/sde1
mdadm: clearing FAULTY flag for device 3 in /dev/md0 for /dev/sdf1
mdadm: clearing FAULTY flag for device 4 in /dev/md0 for /dev/sdf2
mdadm: clearing FAULTY flag for device 6 in /dev/md0 for /dev/sdg1
mdadm: /dev/md0 has been started with 6 drives (out of 7) and 1 spare.
[root@lnxets2 proc]# fsck /dev/md0
fsck 1.32 (09-Nov-2002)
e2fsck 1.32 (09-Nov-2002)
/dev/md0: recovering journal
/dev/md0: clean, 147/6602752 files, 11169427/13193088 blocks
[root@lnxets2 proc]# mount /raid

And lucky me, all came back to life, just as it should.

The lesson here folks, is always make sure your SCSI array, and your server, are running on the same power source…