Messages in this thread |  | | Date | Tue, 2 Oct 2001 07:09:13 +0200 | From | Jakob Østergaard <> |
| |
On Mon, Oct 01, 2001 at 01:09:50PM +0100, Chris Andrews wrote: > Evan Harris (eharris@puremagic.com) said: > > > I have a 6 disk RAID5 scsi array that had one disk go offline through a > > dying power supply, taking the array into degraded mode, and then another > > went offline a couple of hours later from what I think was a loose cable. > > I had much the same happen, except that I lost 6 disks out of 12 (power > failure to one external rack of two), so I had no chance of starting in > degraded mode. In this situation, where there are not enough disks for a > viable raid, what is the recommended solution? In my case, there was nothing > wrong with the six disks, but their superblock event counters were out of > step.
The solution is exactly the same as before: re-create the array with N-1 disks, so that parity reconstruction will not begin.
Find the "oldest" disk and mark that one as failed - in case you lose an entire rack of disks, any one of those should do.
Re-create the RAID, fsck (and don't worry about quite some inconsistency), and most of your data should be back.
If you screw up (eg. re-order disks), your data will never know what hit them.
> > Is the best idea to modify /etc/raidtab as discussed, and run mkraid with > the real force option? What I actually did was to hand-edit the superblocks > on the disks, and got the array going. That experience would lead me to > suggest that there's room for some more options to allow the use of disks > where there's actually nothing wrong, but right now the raid code won't use > them. I'm thinking of a set of '--ignore' options to raidstart: > --ignore-eventcounter, --ignore-failedflag, etc, which an admin could use as > an alternative to trying mkraid.
re-creating the RAID does exactly that: "hand-modifies" the superblocks to let the array run again.
Your idea is pretty good: if you did not have to re-write the superblocks from the raidtab, you would not risk screwing up drive-ordering because of inconsistent raidtabs.
I'd do a patch if I wasn't busy re-constructing/creating/moving/reconfiguring RAID arrays right now ;)
> > Right now it seems that software-raid works well, until it doesn't, at which > point you're stuck - there's very little in the way of tools or overrides to > sort problems out. Something other than 'try mkraid force as a last resort' > would be useful.
You're not stuck. You have plenty of options, just as you stated in your post.
With a hardware solution you'd be *stuck* - not as in "there's no pretty tool", but as in "game over, sucker!" ;)
But I agree with you that the process could be improved, and I really like your suggestion with --ignore-eventcounter (or --try-recover maybe ?).
> > (If anyone thinks this is a good idea, yes, I am volunteering to provide > patches...)
Aha !
I think it's a great idea !
-- ................................................................ : jakob@unthought.net : And I see the elder races, : :.........................: putrid forms of man : : Jakob Østergaard : See him rise and claim the earth, : : OZ9ABN : his downfall is at hand. : :.........................:............{Konkhra}...............: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |