proactive raid5 disk replacement for 2.6.11

Hi,

this is a feature patch that implements 'proactive raid5 disk
replacement' (http://www.arctic.org/~dean/raid-wishlist.html),
that could help a lot on large raid5 arrays built from cheap sata drivers when the IO traffic such large that daily media scan on the disks isn't possible.
linux software raid is very fragile by default, the typical (nervous)
breakdown situation is: I noticed a bad block on a drive, replace it, and the resync fails cause another 2-3 disks have hidden badblocks too. I've to save the disks and rebuild bad blocks with a userspace tool (by hand..), meanwhile the site is down for hours. bad; especially when a pair of simple steps enough to avoid from this atypical problem:
1. dont kick a drive on read error cause it is possible that 99.99% is
useable and will help (to serve and to save data) if another drive show bad sectors in same array
2. let mirror a partially failed drive to a spare _online_ and replace
the source of the mirror with the spare when it's done. bad blocks isn't a problem unless same sector damaged on two disks what's a rare case. in this way is possible to fix an array with partially failed drives without data loss and without downtime

I'm not a programmer just a sysadm who admins a large software sata
array, but my angry got bigger than my laziness, so I made this patch on this weekend.. I'm not understand every piece of the md code (eg. the if-forest of the handle_stripe :) yet, so this patch may be a bug-colony and wrong by design, but I've tested it under heavy stress with both of 'faulty' module and real disks, and it works fine!

ideas, piece of advice, bugfix/enchancement is welcomed!

(I know, raid6 could be another solution for this problem, but that's a
large overhead.)

use:

1. patch the kernel, this one is against 2.6.11
2. type:

# make drives
mdadm -B -n1 -l faulty /dev/md/1 /dev/rd/0
mdadm -B -n1 -l faulty /dev/md/2 /dev/rd/1
mdadm -B -n1 -l faulty /dev/md/3 /dev/rd/2

# make the array
mdadm -C -n3 -l5 /dev/md/0 /dev/md/1 /dev/md/2 /dev/md/3

# .. wait for sync ..

# grow bad blocks as ma*tor does
mdadm --grow -l faulty -p rp454 /dev/md/1
mdadm --grow -l faulty -p rp738 /dev/md/2

# add a spare
mdadm -a /dev/md/0 /dev/rd/4

# -> fail a drive, sync begins <-
# the md/1 will not marked as failed, this is the point, but if you want to, # you can issue this command again!
mdadm -f /dev/md/0 /dev/md/1

# kernel:
# resync from md1 to spare ram4
# added spare for active resync

# .. wonder the read errors from md[12] and the sync goes on!
# feel free to stress the md at this time, mkfs, dd, badblocks, etc

# kernel:
# raid5_spare_active: 3 in_sync 3->0
# /proc/mdstat:
# md0 : active raid5 ram4[0] md3[2] md2[1] md1[0]
# -> ram4 and md1 have same id, this means the spare is a complete mirror,
# if you stop the array you can assembly it with ram4 instead of md1,
# the superblock same both of them

# check the mirror (stop write stress if any)
mdadm --grow -l faulty -p none /dev/md/1
cmp /dev/md/1 /dev/rd/4

# hot-replace the mirrored -partially failed- device with the active spare
#  (yes, mark it as failed again, but if there's a syncing- or synced 'active spare'
#       the -f really fails the device or replace it with the synced spare)
mdadm -f /dev/md/0 /dev/md/1

# kernel:
# replace md1 with in_sync active spare ram4

# and voila!
# /proc/mdstat:
#  md0 : active raid5 ram4[0] md3[2] md2[1]

.. I hope someone can use it for something, for me it's a musthave feature ..

--
dap

this is a feature patch that implements 'proactive raid5 disk replacement'
(http://www.arctic.org/~dean/raid-wishlist.html),
that could help a lot on large raid5 arrays built from cheap sata drivers when the IO traffic such large that daily media scan on the disks isn't possible.
linux software raid is very fragile by default, the typical (nervous) breakdown
situation is: I noticed a bad block on a drive, replace it, and the resync fails cause another 2-3 disks have hidden badblocks too. I've to save the disks and rebuild bad blocks with a userspace tool (by hand..), meanwhile the site is down for hours. bad; especially when a pair of simple steps enough to avoid from this atypical problem:
1. dont kick a drive on read error cause it is possible that 99.99% is useable and will help (to serve and to save data) if another drive show bad sectors in same array
2. let build a mirror _online_ to a spare and replace the source of the mirror with the spare when it's done. bad blocks not a problem unless same sector bad on two disks what's a rare case. in this way is possible to fix an array with partially failed drives without data loss and without downtime

I'm not a programmer just a sysadm who admins a large software sata array, but my
angry got bigger than my laziness, so I made this patch on this weekend.. I'm not understand every piece of the md code (eg. the if-forest of the handle_stripe :) yet, so this patch may be a bug-colony and wrong by design, but I've tested it under heavy stress with both of 'faulty' module and real disks, and it works fine!

ideas, piece of advice, bugfix/enchancement is welcomed!

(I know, raid6 could be another solution for this problem, but that's a large
overhead too.)

use:

1. patch the kernel, this one is against 2.6.11
2. type:

# make drives
mdadm -B -n1 -l faulty /dev/md/1 /dev/rd/0
mdadm -B -n1 -l faulty /dev/md/2 /dev/rd/1
mdadm -B -n1 -l faulty /dev/md/3 /dev/rd/2

# make the array
mdadm -C -n3 -l5 /dev/md/0 /dev/md/1 /dev/md/2 /dev/md/3

# .. wait the sync ..

# grow bad blocks as ma*tor does
mdadm --grow -l faulty -p rp454 /dev/md/1
mdadm --grow -l faulty -p rp738 /dev/md/2

# add a spare
mdadm -a /dev/md/0 /dev/rd/4

# -> fail a drive, sync begins <-
# the md/1 will not marked as failed, this is the point, but if you want to, # you can issue this command again!
mdadm -f /dev/md/0 /dev/md/1

# kernel:
# resync from md1 to spare ram4
# added spare for active resync

# .. wonder the read errors from md[12] and the sync goes on!
# feel free to stress the md at this time, mkfs, dd, badblocks, etc

# kernel:
# raid5_spare_active: 3 in_sync 3->0
# /proc/mdstat:
# md0 : active raid5 ram4[0] md3[2] md2[1] md1[0]
# -> ram4 and md1 have same id, this means the spare is a complete mirror,
# if you stop the array you can assembly it with ram4 instead of md1,
# the superblock same both of them

# check the mirror (stop write stress)
mdadm --grow -l faulty -p none /dev/md/1
cmp /dev/md/0 /dev/rd/4

# hot-replace the mirrored -partially failed- device with the active spare
#  (yes, mark it as failed again, but if there's a syncing ot synced 'active spare'
#	the -f really fails the device or replace it with the synced spare)
mdadm -f /dev/md/0 /dev/md/1

# kernel:
# replace md1 with in_sync active spare ram4

# and voila!
# /proc/mdstat:
#  md0 : active raid5 ram4[0] md3[2] md2[1]

@@ -147,6 +147,7 @@
 #define	R5_UPTODATE	0	/* page contains current data */
 #define	R5_LOCKED	1	/* IO has been submitted on "req" */
 #define	R5_OVERWRITE	2	/* towrite covers whole page */
+#define	R5_FAILED	8	/* failed to read this stripe */
 /* and some that are internal to handle_stripe */
 #define	R5_Insync	3	/* rdev && rdev->in_sync at start */
 #define	R5_Wantread	4	/* want to schedule a read */

@@ -224,6 +225,8 @@
 	int			inactive_blocked;	/* release of inactive stripes blocked,
 							 * waiting for 25% to be free
 							 */        
+	int			mirrorit; /* source for active spare resync */
+
 	spinlock_t		device_lock;
 	struct disk_info	disks[0];
 };

@@ -3545,18 +3547,19 @@
 
 		/* no recovery is running.
 		 * remove any failed drives, then
-		 * add spares if possible
+		 * add spares if possible.
+		 * Spare are also removed and re-added, to allow
+		 * the personality to fail the re-add.
 		 */
-		ITERATE_RDEV(mddev,rdev,rtmp) {
+		ITERATE_RDEV(mddev,rdev,rtmp)
 			if (rdev->raid_disk >= 0 &&
-			    rdev->faulty &&
+			    (rdev->faulty || ! rdev->in_sync) &&
 			    atomic_read(&rdev->nr_pending)==0) {
+printk("md_check_recovery: hot_remove_disk\n");
 				if (mddev->pers->hot_remove_disk(mddev, rdev->raid_disk)==0)
 					rdev->raid_disk = -1;
 			}
-			if (!rdev->faulty && rdev->raid_disk >= 0 && !rdev->in_sync)
-				spares++;
-		}
+
 		if (mddev->degraded) {
 			ITERATE_RDEV(mddev,rdev,rtmp)
 				if (rdev->raid_disk < 0

@@ -3764,4 +3771,5 @@
 EXPORT_SYMBOL(md_wakeup_thread);
 EXPORT_SYMBOL(md_print_devices);
 EXPORT_SYMBOL(md_check_recovery);
+EXPORT_SYMBOL(kick_rdev_from_array);	// fixme
 MODULE_LICENSE("GPL");

sorry, the previous patch doesn't work against vanilla kernel, this one
do..

--
dap

this is a feature patch that implements 'proactive raid5 disk
replacement' (http://www.arctic.org/~dean/raid-wishlist.html),
that could help a lot on large raid5 arrays built from cheap sata drivers when the IO traffic such large that daily media scan on the disks isn't possible.
linux software raid is very fragile by default, the typical (nervous)
breakdown situation: I noticed a bad block on a drive, replace it, and the resync fails cause another 2-3 disks has hidden badblocks too. I've to save the disks and rebuild bad blocks with a userspace tool (by hand..), meanwhile the site is down for hours. bad; especially when a pair of simple steps enough to avoid from this atypical problem:
1. dont kick a drive on read error cause it is possible that 99.99% is
useable and will help (to serve and to save data) if another drive show bad sectors in same array
2. let to mirror a partially failed drive to a spare _online_ and replace
the source of the mirror with the spare when it's done. bad blocks isn't a problem unless same sector damaged on two disks what's a rare case. in this way is possible to fix an array with partially failed drives without data loss and without downtime

I'm not a programmer just a sysadm who admins a large software sata
array, but my angry got bigger than my laziness, so I made this patch on this weekend.. I don't understand every piece of the md code (eg. the if-forest of the handle_stripe :) yet, so this patch may be a bug-colony and wrong by design, but I've tested it under heavy stress with both of 'faulty' module and real disks, and it works fine!

ideas, piece of advice, bugfix/enchancement is welcomed!

(I know, raid6 could be another solution for this problem, but that's a
large overhead.)

use:

1. patch the kernel, this one is against 2.6.11
2. type:

# make drives
mdadm -B -n1 -l faulty /dev/md/1 /dev/rd/0
mdadm -B -n1 -l faulty /dev/md/2 /dev/rd/1
mdadm -B -n1 -l faulty /dev/md/3 /dev/rd/2

# make the array
mdadm -C -n3 -l5 /dev/md/0 /dev/md/1 /dev/md/2 /dev/md/3

# .. wait for sync ..

# grow bad blocks as ma*tor does
mdadm --grow -l faulty -p rp454 /dev/md/1
mdadm --grow -l faulty -p rp738 /dev/md/2

# add a spare
mdadm -a /dev/md/0 /dev/rd/4

# -> fail a drive, sync begins <-
# the md/1 will not marked as failed, this is the point, but if you want to, # you can issue this command again!
mdadm -f /dev/md/0 /dev/md/1

# kernel:
# resync from md1 to spare ram4
# added spare for active resync

# .. wonder the read errors from md[12] and the sync goes on!
# feel free to stress the md at this time, mkfs, dd, badblocks, etc

# kernel:
# raid5_spare_active: 3 in_sync 3->0
# /proc/mdstat:
# md0 : active raid5 ram4[0] md3[2] md2[1] md1[0]
# -> ram4 and md1 has same id, this means the spare is a complete mirror,
# if you stop the array you can assembly it with ram4 instead of md1,
# the superblock same both of them

# check the mirror (stop write stress if any)
mdadm --grow -l faulty -p none /dev/md/1
cmp /dev/md/1 /dev/rd/4

# hot-replace the mirrored -partially failed- device with the active spare
#  (yes, mark it as failed again, but if there's a syncing- or synced 'active spare'
#       the -f really fails the device or replace it with the synced spare)
mdadm -f /dev/md/0 /dev/md/1

# kernel:
# replace md1 with in_sync active spare ram4

# and voila!
# /proc/mdstat:
#  md0 : active raid5 ram4[0] md3[2] md2[1]

.. I hope someone can use it for something, for me it's a musthave feature ..

@@ -147,6 +147,7 @@
 #define	R5_UPTODATE	0	/* page contains current data */
 #define	R5_LOCKED	1	/* IO has been submitted on "req" */
 #define	R5_OVERWRITE	2	/* towrite covers whole page */
+#define	R5_FAILED	8	/* failed to read this stripe */
 /* and some that are internal to handle_stripe */
 #define	R5_Insync	3	/* rdev && rdev->in_sync at start */
 #define	R5_Wantread	4	/* want to schedule a read */

@@ -224,6 +225,8 @@
 	int			inactive_blocked;	/* release of inactive stripes blocked,
 							 * waiting for 25% to be free
 							 */        
+	int			mirrorit; /* source for active spare resync */
+
 	spinlock_t		device_lock;
 	struct disk_info	disks[0];
 };

@@ -3545,18 +3547,19 @@
 
 		/* no recovery is running.
 		 * remove any failed drives, then
-		 * add spares if possible
+		 * add spares if possible.
+		 * Spare are also removed and re-added, to allow
+		 * the personality to fail the re-add.
 		 */
-		ITERATE_RDEV(mddev,rdev,rtmp) {
+		ITERATE_RDEV(mddev,rdev,rtmp)
 			if (rdev->raid_disk >= 0 &&
-			    rdev->faulty &&
+			    (rdev->faulty || ! rdev->in_sync) &&
 			    atomic_read(&rdev->nr_pending)==0) {
+printk("md_check_recovery: hot_remove_disk\n");
 				if (mddev->pers->hot_remove_disk(mddev, rdev->raid_disk)==0)
 					rdev->raid_disk = -1;
 			}
-			if (!rdev->faulty && rdev->raid_disk >= 0 && !rdev->in_sync)
-				spares++;
-		}
+
 		if (mddev->degraded) {
 			ITERATE_RDEV(mddev,rdev,rtmp)
 				if (rdev->raid_disk < 0

@@ -3764,4 +3771,5 @@
 EXPORT_SYMBOL(md_wakeup_thread);
 EXPORT_SYMBOL(md_print_devices);
 EXPORT_SYMBOL(md_check_recovery);
+EXPORT_SYMBOL(kick_rdev_from_array);	// fixme
 MODULE_LICENSE("GPL");

After my experience with a broken raid5 (read the list) I think the "partially failed disks" feature you describe is really useful. I agree with you that this kind of error is rather common.

Claas Hilbrecht
http://www.jucs-kramkiste.de

Hi,

...

I just had a fast look over your patch, so please forgive me if I could have found the answer in the code.
What I'm wondering about is how does your patch make the whole system behave in case of more harmful errors?
The read errors you are talking about are quite harmless regarding subsequent access to the device. Unfortunately there *are* errors (even read errors, too), especially when you are talking about cheap IDE (ATA, SATA) equipment, where subsequent access to the device results in infinite (bus-)lockups. I think, this is the reason why Software-RAID does never ever touch a failing drive again. If you are changing this behaviour in general, you risk lock-ups of the raid-device just because one of the drives got locked up.
What I did not find in your patch is some differentiation between the harmless and harmful error conditions. I'm not even sure, if this is possible at all.

regards
Mario

Um mit einem Mann gluecklich zu werden, muss man ihn sehr gut
verstehen und ihn ein bisschen lieben.
Um mit einer Frau gluecklich zu werden, muss man sie sehr lieben
und darf erst gar nicht versuchen, sie zu verstehen.

yes, I understand your point, but I think the low level ATA driver must
be fixed if that lets a drive to lock up. as I know, the SCSI layer send an abort/reset to the device driver if a request not served within a timeout value ("hey, give me some kind of result, now!"), it's a good operation, only a really braindead driver ignores that alarm..
as I saw it in practice, modern sata drivers doesn't let a drive to
lock up, others should be teached about "timeout"

unfortunately, bad blocks are often served slowly from damaged disks
and the array tries to access those periodically in this way, it could slow down the array. I think about it, and would be a good starting practice to build a table called 'this disk is bad for this stripe', an insert occurs after a read error, a delete after if stripe is rewritten to the disk. it reduces error lines in dmesg about bad sectors too

currently it doesn't tolerate write errors, if a write fails, the drive
gets kicked immediately, so a fully failed disk will not be accessed forever.. anyway, it's really hard to determine what's a harmful error (at this layer we've got a bit for that:), maybe we should to compute a success-fail ratio (%) for a time, or scan the 'this disk is bad for this stripe' table for errors and disable the disk if count of bad blocks is over a user-defined threshold

summary (todo..!):
- I think, we shouldn't care about drive lockups
- would be good a 'this disk is bad for this stripe' table to speed up
array with partially failed drives, easy to implement it
- make a switch to choose 'partially failed' feature on per-array basis
after the patch is being applied (eg. to remain compatible with buggy - forever locking- device drivers)

well?

 dap

Horrible idea.
Once you have a bad block on one disk, you have definitively lost your data redundancy.
That's bad.

What should be done about bad blocks instead of your suggestion is to try and write the data back to the bad block before kicking the disk. If this succeeds, and the data can then be read from the failed block, the disk has automatically reassigned the sector to the spare sector area. You have redundancy again and the bad sector is "fixed".

If you're having a lot of problems with disks getting kicked because of bad blocks, then you need to diagnose some more to find out what the actual problem is.

My best guess would be that either you're using an old version of MD that won't try to write to bad blocks, or the spare area on your disk is full, in which case it should be replaced. You can check the status of spare areas on disks with 'smartctl' or similar.

Hm, I think you don't understand the point, yes, that should be
replaced as soon as you can, but the good sectors of that drive can be useful if some bad sectors are discovered on an another drive during the rebuilding. we must keep that drive in sync to keep that sectors useful, this is why the badblock tolerance is.
It is the common error if you've lot of disks and can't do daily media
checks because of the IO load.

Which version of md tries to rewrite bad blocks in raid5?

I've problem with "hidden" bad blocks (never mind if that's repairable
or not), the rewrite can't help, cause you don't know if that's there until you don't try to rebuild the array from degraded state to a replaced disk. I want to avoid from the rebuiling from degraded state, this is why the 'proactive replacement' feature is. handling of *known* bad blocks is an another subject, yes, that should be rewritten asap (but I think, not certainly when detected, see my previous mails, a problem is you never can be sure is that succeed or not).

--
dap

Ok, I misunderstood you. Sorry, and thanks for the explanation.

Agreed.

Haven't followed the discussions closely, but I sure hope that the newest version does. (After all, spare areas are a somewhat old feature in harddrives..)

Got it now. Super. Sounds good ;-).
(I hope that you're simply rebuilding to a spare before kicking the drive, not doing something funky like remapping sectors or some such..)

Sorry, but no - not yet.
Over-writing bad blocks is on my todo list, and will probably happen this year, but it certainly is available yet.

NeilBrown