2 out of 3 disks in raid is considered spares?

[GBOSTROM]

Hi all,

after a crash in an OS disk, I have tried to re-generate a soft-Raid5 without success.

The new machine contains the disks as:
/dev/sd[def]1

Analysing the disk content with

>mdadm -D /dev/sd[def]1

One can read out that all disks belong to a 3 disk raid with the same UUID, their checksum
is clear and have the same update time.
The strage thing is that that 2 out of the 3 disks are considered to be spares.

Is there anyway that one can change this and get the array to start again.

Thanks,
G

 

[Mercutio]

What is mdadm telling you when you try to start the array?

 

[GBOSTROM]

ns201:~ # mdadm --assemble -v /dev/md3 /dev/sdd1 /dev/sde1 /dev/sdf1
mdadm: looking for devices for /dev/md3
mdadm: /dev/sdd1 is identified as a member of /dev/md3, slot 2.
mdadm: /dev/sde1 is identified as a member of /dev/md3, slot -1.
mdadm: /dev/sdf1 is identified as a member of /dev/md3, slot -1.
mdadm: no uptodate device for slot 0 of /dev/md3
mdadm: no uptodate device for slot 1 of /dev/md3
mdadm: added /dev/sde1 to /dev/md3 as -1
mdadm: failed to add /dev/sdf1 to /dev/md3: Device or resource busy
mdadm: added /dev/sdd1 to /dev/md3 as 2
mdadm: /dev/md3 assembled from 1 drive and 1 spare - not enough to start the array.

 

[Mercutio]

You might have to remove /dev/sdf1 from the array and re-add it since it appears that it dropped out of the array.

 

[GBOSTROM]

Sorry for the posts, but I do appreciate your help....

I don't know exactly how to do this. I tried with the following, and it doesn't work:
ns201:~ # mdadm --manage /dev/md3 --fail /dev/sdf1
mdadm: cannot get array info for /dev/md3
ns201:~ # mdadm --stop /dev/md3
mdadm: stopped /dev/md3
ns201:~ # mdadm --manage /dev/md3 --fail /dev/sdf1
mdadm: error opening /dev/md3: No such file or directory

Obviously, I don't know enough to do this operation. Can you help me?

Thanks,
G

 

[Mercutio]

You could try starting with
mdadm --remove /dev/md3 /dev/sdf1

Then re-add
mdadm --add /dev/md3 /dev/sdf1

And then assemble again.

I'm going to go ahead and guess that you're dealing with a RAID of 5400RPM SATA drives, right?

 

[Mercutio]

Oh. Big, important step to not forget to do:

Make sure you copy your partition information for your array with sfdisk before you pull the drive out of the array.

 

[GBOSTROM]

The statement about 5400 is correct. Problem?
The re-add operation don't succeed. See below.
status of md3 after removal of sdf.

ns201:~/raidcheck # cat /proc/mdstat
Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md3 : inactive sdd1[3](S) sde1[4](S)
976751728 blocks super 1.0

ns201:~/raidcheck # mdadm --add /dev/md3 /dev/sdf1
mdadm: cannot get array info for /dev/md3

ns201:~/raidcheck # ll /dev/md*
.....
brw-rw---- 1 root disk 9, 3 Jul 26 09:29 /dev/md3

Strange that "cannot get array info" occurs when it is listed. Both in mdstat and ll??
If I repeat the operation with a call to mdadm --stop /dev/md3 the same thing happens, i.e. "cannot get array info..."


/G

 

[ddrueding]

Recent cheap 5400RPM SATA drives have been incredibly unreliable in RAID arrays. There is much speculation as to why.