Hi Shaohua,
Many thanks for your reply.
How about the following WARN_ON() in handle_stripe_clean_event()???
if (test_and_clear_bit(R5_SkipCopy, &dev->flags)) {
WARN_ON(test_bit(R5_UPTODATE, &dev->flags));
}
Sometimes it will be triggered as well but I can't find the exactly
way to reproduce it.
I would like to know if it is suitable to remove it as well or not.
2016-04-30 5:17 GMT+08:00 Shaohua Li <shli@xxxxxxxxxx>:
> On Fri, Apr 29, 2016 at 06:54:10PM +0800, Joey Liao wrote:
>> Hi all,
>>
>> For improving the I/O performance, we try to enable the raid 5
>> skip_copy feature by default. It indeed has some benefit, however, it
>> will always (not a random issue) dump the following call trace
>> repeatedly when we try to write the raid 5 block device. It is related
>> to the following codes in handle_stripe_clean_event() in raid5.c.
>>
>> WARN_ON(test_bit(R5_SkipCopy, &dev->flags));
>> WARN_ON(dev->page != dev->orig_page);
>>
>> Is it a known bug for skip_copy feature?
>> Does it do harm to the data integrity?
>> If we would like to prevent this call trace, for your suggestion how
>> should we do to modify the source code?
>
> Looks the two WARN_ON should be deleted. if the dev has R5_LOCKED, it's legit
> the dev has SkipCopy set and page != orig_page. I'll delete the code. This will
> not harm to data integrity.
>
> Thanks,
> Shaohua
--
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
