I donot think that is how raid5 works. You should not have removed the first faulty disk in the first place. I think how raid5 works is that it tends to have an parity information stored in an particular drive. Correct me on this if it is wrong? On Sat, Jul 11, 2009 at 1:16 PM, Thomas Kenyon<zhadnost@xxxxxxxxxxxxxx> wrote: > My server at home operates a 4 disk software RAID 5 array which is > normally mounted at /. > > At the moment I am using mdadm v2.6.7.2 (I don't know which version > built the array). > > One of the disks appeared to have developed a fault, an I/O error > would be produced and the array would rebuild to try and mao round it, > and once it had finished there'd be another I/O error and it would > start again. > > I marked the drive as faulty, removed it from the array, replaced it > with a nother drive, replicated the partition map and added it to the > array. > > As expected the drive started being built. > > I'm not sure if it had finished by this point, but another disk > produced an I/O error which broke the array. > > Now I'm trying to recover any data I can from it. > > The partitions in the array are sd[abcd]1. (SATA controller). > > sdb is the drive that originally failed and has been replaced. sdc is > the drive that took everything down. > > When I first try to assemble the array, this message appears in kernel messages. > > md: kicking non-fresh sdc1 from array! > > and this appears in the console. > > mdadm: /dev/md0 assembled from 2 drives and 1 spare - not enough to > start the array. > > even if I use --force. > > with this in mdstat > > Personalities : [raid6] [raid5] [raid4] > md0 : inactive sdd1[2](S) sdc1[1](S) sdb1[5](S) sda1[4](S) > 1937888128 blocks super 1.0 > > unused devices: <none> > > (well, all the [S], except the one on sdb1 appearing is new). > > If I try to fail and remove sdc1 and then reinsert it I get. > > mdadm /dev/md0 -f /dev/sdc1 > mdadm: cannot get array info for /dev/md0 > > from examine I get > > /dev/sda1: > Magic : a92b4efc > Version : 1.0 > Feature Map : 0x0 > Array UUID : 62f0dee0:e3a81d0c:68df2ad8:1ecb435b > Name : 'chef':1 > Creation Time : Mon Jul 21 15:58:36 2008 > Raid Level : raid5 > Raid Devices : 4 > > Avail Dev Size : 968944072 (462.03 GiB 496.10 GB) > Array Size : 2906832000 (1386.09 GiB 1488.30 GB) > Used Dev Size : 968944000 (462.03 GiB 496.10 GB) > Super Offset : 968944328 sectors > State : clean > Device UUID : 0bf37dbc:000ee685:7bcf601b:ff125af1 > > Update Time : Fri Jul 10 18:45:04 2009 > Checksum : ef734a25 - correct > Events : 19518 > > Layout : left-symmetric > Chunk Size : 64K > > Array Slot : 4 (failed, failed, 2, failed, 3) > Array State : __uU 3 failed > > /dev/sdb1: > Magic : a92b4efc > Version : 1.0 > Feature Map : 0x0 > Array UUID : 62f0dee0:e3a81d0c:68df2ad8:1ecb435b > Name : 'chef':1 > Creation Time : Mon Jul 21 15:58:36 2008 > Raid Level : raid5 > Raid Devices : 4 > > Avail Dev Size : 968944200 (462.03 GiB 496.10 GB) > Array Size : 2906832000 (1386.09 GiB 1488.30 GB) > Used Dev Size : 968944000 (462.03 GiB 496.10 GB) > Super Offset : 968944328 sectors > State : clean > Device UUID : bb71f618:9d9be6e2:84bd3fdb:02543dfb > > Update Time : Fri Jul 10 18:45:04 2009 > Checksum : 72ae8ca8 - correct > Events : 19518 > > Layout : left-symmetric > Chunk Size : 64K > > Array Slot : 5 (failed, failed, 2, failed, 3) > Array State : __uu 3 failed > > /dev/sdc1: > Magic : a92b4efc > Version : 1.0 > Feature Map : 0x0 > Array UUID : 62f0dee0:e3a81d0c:68df2ad8:1ecb435b > Name : 'chef':1 > Creation Time : Mon Jul 21 15:58:36 2008 > Raid Level : raid5 > Raid Devices : 4 > > Avail Dev Size : 968944200 (462.03 GiB 496.10 GB) > Array Size : 2906832000 (1386.09 GiB 1488.30 GB) > Used Dev Size : 968944000 (462.03 GiB 496.10 GB) > Super Offset : 968944328 sectors > State : clean > Device UUID : 0259688e:21902f87:a4da25cd:a5042e6f > > Update Time : Fri Jul 10 18:45:04 2009 > Checksum : f2402efa - correct > Events : 19375 > > Layout : left-symmetric > Chunk Size : 64K > > Array Slot : 1 (failed, failed, 2, failed, 3) > Array State : __uu 3 failed > > /dev/sdd1: > Magic : a92b4efc > Version : 1.0 > Feature Map : 0x0 > Array UUID : 62f0dee0:e3a81d0c:68df2ad8:1ecb435b > Name : 'chef':1 > Creation Time : Mon Jul 21 15:58:36 2008 > Raid Level : raid5 > Raid Devices : 4 > > Avail Dev Size : 968944072 (462.03 GiB 496.10 GB) > Array Size : 2906832000 (1386.09 GiB 1488.30 GB) > Used Dev Size : 968944000 (462.03 GiB 496.10 GB) > Super Offset : 968944328 sectors > State : clean > Device UUID : 1f3b1479:3e01d8dd:d8ce565a:cb13e780 > > Update Time : Fri Jul 10 18:45:04 2009 > Checksum : d27e859e - correct > Events : 19518 > > Layout : left-symmetric > Chunk Size : 64K > > Array Slot : 2 (failed, failed, 2, failed, 3) > Array State : __Uu 3 failed > > As you can see sdc1's event count is more than a little out, oddly > sdb1 is in State: clean. > > I've run out of ideas, can somoneone please give me a point in the > right direction as to how to recover some of the data from this. > > TIA for any help received. > -- > 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 > -- -- Sujit K M -- 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
