> Your initial post suggested you knew which drive was flaky. Now you > indicate you don't know which, if any, is flaky. This suggests you have > no idea why your array is slow. Well, I always have an indication which drive is flaky, based on dmesg output (e.g. hard resetting ATA3 link, etc). However, sometimes it reports that more than one drive has problems, and I can't be 100% sure which of the flaky drives is the "more flaky" one :) and it is too late to replace any of them, since there is high chance that the other one dies as well during resync (which happened to me few times already). From my point of view it is better for me to keep the array in sync as long as I can, and copy the data somewhere as fast as I can. NeilBrown's suggestion looks like very simple logic needed to implement, however the amount of nested ANDs and ORs in fetch_block() in raid5.c is too huge to my understanding :-) so I'm giving up :) Tomas M -- 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
