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. 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). Thanks, Eryu -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
