Hi Frederick, On 05/04/2013 12:51 PM, Frederick Gnodtke wrote: > Hi, > > I hope someone can help me with this as I am struggling with it since > this morning. We may be able to help you. Some critical information is missing. For the record, running raid5 when you have a hot spare available to make it a raid6 is pretty much insane. > The following scenario: I have a softwareraid 5 created using mdadm. > It consisted out of 5 Disks, each of them 2000GB with one as spare-drive. > The original mdadm.conf looked like this: [trim /] > Everything was fine until this morning I tried to open a file and got an > I/O-Error. I rebooted the computer, stopped the raid, did an smartctl -t > long on all drives belonging to the raid, but they all seem to run quiet > well. > Reassembling it using mdadm --assemble --scan --force did not lead to > anything so I tried to recreate it using "mdadm --create /dev/md0 > --assume-clean --raid-devices=5 --level=5 /dev/sd[abdef] Really bad choice. Advice to use "--create --assume-clean" is scattered around the 'net, but there are terrible pitfalls. > It created an array but there was no filesystem to mount. > fsck could not detect an filesystem and I didn't relocate any "bad > blocks" as I was afraid this might reduce my chance to repair the raid > to zero. The device order you specified is certainly wrong, based on your original superblocks. > The original Superblocks of all disks befor recreating the array looked > like this (The raid already failed when I captured this): [trim /] You don't show the original superblock for /dev/sda. We need it. >From the given superblocks, your order would be /dev/sd{?,f,e,?,d,?}, where the question marks would be various combinations of a, b, and c. The roles of sdb and sdc show as spare, either of which could have been the original spare. Please look in your system's syslog to see if you can find the raid assembly report from the last boot before the problem surfaced. It would be an alternate source of drive roles. If you find that in syslog, there's a good chance you will also be able to find the drive error reports in syslog for the kickout of your drives. Show us the excerpts. > Is there any chance to recover the raid? Yes. > Has anybody any idea? You may have to try multiple combinations of drive orders if it cannot be figured out from other information. You *must* not mount your filesystem until we are certain the order is correct. > As I am just a poor student I didn't quiet have the money to do backups > so my private data would be lost if the raid failed. Excuses don't really matter. Either we can help you or we can't. Everyone has limited funds, to some extent. I recommend you prioritize your personal data as to that which gets backed up and that which doesn't. Most people can't afford to *not* back up at least part of their data, but don't know until they lose it. > I would really appreciate your help! When people report array problems for drives that all appear healthy, certain suspicions arise. Please also provide: 1) "smartctl -x" output for each drive. 2) "uname -a" output 3) "mdadm --version" output Phil -- 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