Yep. I got mdadm after I had sent this. It's still a bit flaked out (I'm having a lot of trouble getting the filesystem back), but the devices are online. BTW - The event counter on the failed device was 0000000c, and I did not re-attach it. The file-system should have been stable (few writes) -- Eric On Wed, 27 Aug 2003, mjstumpf wrote: > > > /dev/md3 = RAID5, /dev/sde1 + /dev/sdf1 + /dev/sdg1 + /dev/sdh1 > > /dev/md4 = RAID5, /dev/sdi1 + /dev/sdj1 + /dev/sdk1 + /dev/sdl1 > > /dev/md5 = RAID0, /dev/md3 + /dev/md4 > > > When I try to run raidstart /dev/md3 I get - > > > > Aug 26 20:37:15 davis kernel: [events: 0000000f] > > Aug 26 20:37:15 davis kernel: [events: 0000000f] > > Aug 26 20:37:15 davis kernel: [events: 0000000d] > > I am most definitely NOT the expert, however I would recommend getting > "mdadm" (search this list for the tool) and using it exclusively from now > on. The FAQ/howto is badly out of date. > > It would be interesting to see the event counter on the failed device. > > With mdadm you can reassemble the array and start it even though the event > counters disagree. I had to do this recently when a failed drive caused a > partial boot, and my array (on attempting to boot) was incrementing the > first of the drives' event counters. I knew nothing had changed, so it > was very safe to force. > > This might be a similar situation. I'd guess the worst thing you would > face is a few corrupted files. > > > > - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
