> On Jun 23, 2015, at 6:09 PM, Phil Turmel <philip@xxxxxxxxxx> wrote: > > On 06/23/2015 05:21 PM, Jared Mauch wrote: >> Let me know what debugging/details might be interesting to collect. > > A good sequence of events (from bash history perhaps) with corresponding > log messages is always helpful. Your initial report was pretty good. I looked, this seems to have aged out. Plus, bash.. meh.. tcsh :) >> Based on the Events# being in-sync, I am going to assume that the drives >> may be operating in a protected-type mode even if the output doesn’t >> concur. > > I think that's unlikely. In replace, one drive responds for sectors > below the progress mark, and the other drive responds for sectors above it. >> I can say this state seems to survive reboots. > > That suggests you give a vanilla (or near-vanilla) kernel a try with one > of the various liveCDs that have them. I personally find the one from > sysrescuecd.org to be most convenient, but I'm a gentoo guy :-) I used to run SLS back in the day before everyone got all crazy with the distributions. > Otherwise, consider adding a third drive to see if it will rebuild and > break the deadlock. I’m currently out of physical slots for drives so this poses a challenge, plus the machine is 250 mi away, but I do have console/IPMI. > I should have to say, but I hope you have a backup :-) There is a qcow file on the mirrored SSDs which seems to be ok as I was able to SCP it off to another host once I found space to toss a 800gb file. I may even be mailing you from said qcow. it seems others were able to perhaps recover from not quite exact situations by stopping and forcing a reassemble, but as copying 800gb would take a few hours again, I’m nervous to perform such an action. e.g.: http://ubuntuforums.org/showthread.php?t=1707416 I guess this means when I visit the machine next week I should take the large external drive array and sas controller card I have here at home as a checked bag. - Jared-- 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
