We left our heroes yesterday with a broken RAID 5 due to read errors on multiple disks. (Read part I: here)

A great starting point is raidextract by Peter Benie which attempts to re-assemble a RAID5. His web-page on this tool also serves as a great overview in the inner workings of standard RAID 5.

The first problem we stumbled upon is the fact that it assumes a certain pattern of the Parity blocks. (All examples from here on assume 4 disks, since that is what we had. But of course that's all applicable to any number of disks)

Adapting the example from his page:

Our Linux-mdraid unfortunately didn't conform to this expectation. Not only does it start with parity on the last disk (which raidextract would support with --rotate), but it also moves the parity block 'backward' instead of 'forward'.

The correct allocation order looks like this:

A quick&dirty hack to raidextract to implement this order:

--- raidextract.c	2008-07-26 11:33:53.000000000 +0200
+++ raidextract-new.c	2010-06-28 13:49:54.000000000 +0200
@@ -316,8 +316,10 @@
 	int paritydisk=(stripe / (disks-1) + rotate) % disks;
 	int len=stripesize-offset;
 	int bytes;
+	int ndisk;
 	char *ptr;
 
+	ndisk=(disk-paritydisk+3)%disks;
 	if (!noparity && paritydisk <= disk) disk++;
 	if (len>raidlen) len=raidlen;
 	if (winoffset+len > datasize) len=datasize-winoffset;
@@ -337,7 +339,7 @@
 	raidstart+=len;
 	raidlen-=len;
 
-	ptr=window[disk][windowalt]+winoffset;
+	ptr=window[ndisk][windowalt]+winoffset;
 	while (len)
 	{
 		bytes=write(STDOUT_FILENO, ptr, len);

A run on an error-free test-RAID confirms this and extracted it correctly. Yay!

continued in part III, coming soon

– Sec