On Wed, Jul 8, 2020 at 4:29 AM Michal Soltys <msoltyspl@xxxxxxxxx> wrote: > > On 7/7/20 12:08 AM, Song Liu wrote: > >> > >> So, what kind of next step after this ? > > > > Sorry for the delay. I read the log again, and found the following > > line caused this issue: > > > > [ +16.088243] r5l_write_super_and_discard_space set MD_SB_CHANGE_PENDING > > > > The attached patch should workaround this issue. Could you please give it a try? > > Yea, this solved the issue - the raid assembled correctly (so the patch > is probably a good candidate for lts kernels). Thanks for testing the patch. I will work on applying it to upstream. > > Thanks for helping with this bug. > > Underlying filesystems are mountable/usable as well - albeit read-only > fsck (ext4) or btrfs check do find some minor issues; tough to say at > this point what was the exact culprit. > > In this particular case - imho - one issue remains: the assembly is > slower than full resync (without bitmap), which outside of some > performance gains (writeback journal) and write-hole fixing - kind of > completely defeats the point of having such resync policy in the first > place. Totally agreed that we need to improve the recovery speed. I will also look into that. Thanks again! Song
