On 10/10/2017 10:11 AM, Curt wrote: >> >> I've never seen this before, and don't have time at the moment >> to read the code to understand what it means. > I did a search and here's the comment before the code I found spits > out that error message. I don't know if it's useful to you > /* reshape_position is a little messy. > * Its value must be a multiple of the larger > * chunk size, and of the "after" data disks. > * So when reverting we need to change it to > * be a multiple of the new "after" data disks, > * which is the old "before". > * If it isn't already a multiple of 'before', > * the only thing we could do would be > * copy some block around on the disks, which > * is easy to get wrong. > * So we reject a revert-reshape unless the > * alignment is good. > */ > if (reshape_sectors % reshape_chunk) > > That doesn't read good for me. Yup. >> Probably. But yeah, "fit state". That's the magic. /-: >> > What are the chances if I just do an assemble and let it try to grow > again that it will complete without issue? Then assuming it completes, > that I will have most my data still? Yeah, try without the revert. You don't have to wait for the reshape to finish to grab your critical files off of it. In fact, you might want to freeze the reshape to minimize the chance of hitting a not-yet-found URE. Phil -- 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
