On Wed, Dec 30, 2015 at 09:15:44PM -0500, Sanidhya Solanki wrote: > On Wed, 30 Dec 2015 18:18:26 +0100 > David Sterba <[email protected]> wrote: > > > That's just the comment copied, the changelog does not explain why > > it's ok to do just the run_xor there. It does not seem trivial to me. > > Please describe that the end result after the code change is expected. > > In the RAID 6 case after a failure, we discover that the failure > affected the entire P stripe, without any bad data occurring. Hence, we > xor the previously stored parity data to return the data that was lost > in the P stripe failure. > > The xor-red data is from the parity blocks. Hence, we are left with > recovered data belonging to the P stripe.
If the data a rerecovered, why is -EIO still returned? Also, I see some post-recovery steps eg. for the damaged P stripes (at label pstripes) and I'd expect something similar for the case you're fixing. I'm not familiar with the raid56 implementation but the fix looks suspiciously trivial and I doubt that the xor was omitted out of laziness. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
