At 12/24/2016 05:45 PM, Eryu Guan wrote:
On Thu, Dec 22, 2016 at 10:02:51AM +0800, Qu Wenruo wrote:
Although by design, btrfs scrub and replace share the same code path, so
they are exclusive to each other.
But the fact is, there is still some critical region not protected well,
so we can have the following kernel panic, especially easy to trigger on
RAID5/6 profiles.
Could btrfs/069 reproduce the panic? It also races scrub and replace,
but with fsstress running in background, raid5/6 profiles are part of
the default test configs.
Yes, but the possibility is very low and depends on the test machine.
I never reproduced it with btrfs/069 on all my VMs, but can produce it
on my physical machines.
Nor btrfs/069 supports TIME_FACTOR to improve the possibility.
Also, is there a known fix available in Linus tree or btrfs tree? If
not, I'd push this new test after there's a known fix (if it's worth a
new test).
Not yet, still WIP.
I'll CC you as the fix is submitted.
Thanks,
Qu
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
