After some more tests:
A running system with a correct raid system will not have any trouble
rebooting and re-assembling.
but a system without one of the disks also crashes the raid in a reboot.
I know we should have a fully 4 disk synchronized raid system. But it
seems to me it should still be able to assemble a raid system without
the forth disk, multiple times. Is there something that I should change
in my configuration or any things I can do to prevent this?
Guido.
Correct System print:
[root@localhost ~]# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90.03
Creation Time : Thu May 11 12:05:31 2006
Raid Level : raid5
Array Size : 732419136 (698.49 GiB 750.00 GB)
Device Size : 244139712 (232.83 GiB 250.00 GB)
Raid Devices : 4
Total Devices : 4
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu May 11 13:36:45 2006
State : clean
Active Devices : 4
Working Devices : 4
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 32c52389:27a260ee:ed154946:5e56f4ed
Events : 0.4
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
3 8 49 3 active sync /dev/sdd1
Does not have this problem.
Missing a drive print:
/dev/md0:
Version : 00.90.03
Creation Time : Thu May 11 12:05:31 2006
Raid Level : raid5
Device Size : 244139712 (232.83 GiB 250.00 GB)
Raid Devices : 4
Total Devices : 3
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu May 11 14:09:09 2006
State : active, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
UUID : 32c52389:27a260ee:ed154946:5e56f4ed
Events : 0.455
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
2 8 33 2 active sync /dev/sdc1
3 0 0 3 removed
Guido Moonen wrote:
Hi,
Computers in the field will be able to complete the whole cycle of
recovering and having a redundent array. but this is a situation that
can happen, and we are not sure what is causing this problem. I will
let one complete the this recovery and try to reproduce this bug. But
when a customer will replace one the drives this process is started
again and there will be a period where the system is not full proof.
System use:
This system will record (24/7) a single channel and saves the recorded
data (MPEG) on a raid device. The system must be able to hold 90 days
of recorded material for compliance regulation. When the raid fails
users can lose upto 90 days of mpeg which is not acceptable for
compliance (They must be able to produce the recorded mpeg for 90
days). So we would like to know if this failure can be avoided, or if
there is another configuration which makes it possible to recover from
this state.
Guido.
Neil Brown wrote:
On Thursday May 11, guido.moonen@xxxxxxx wrote:
Hi,
I'm running a raid5 system, and when I reboot my raid seems to be
failing. (One disk is set to spare and other disk seems to be oke in
the detials page but we get a INPUT/OUTPUT error when trying to
mount it)
We cannot seem te find the problem in this setup.
...
State : clean, degraded, recovering
^^^^^^^^^^
Do you ever let the recovery actually finish? Until you do you don't
have real redundancy.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
