On Mon, Jul 10, 2017 at 09:18:24AM -0700, Darrick J. Wong wrote:
> On Sun, Jul 09, 2017 at 10:08:18PM +0800, Eryu Guan wrote:
> > On Fri, Jul 07, 2017 at 11:49:37PM -0700, Darrick J. Wong wrote:
> > > On Fri, Jul 07, 2017 at 08:01:43PM +0800, Eryu Guan wrote:
> > > > Hi all,
> > > >
> > > > I recently hit a repeatable sb_fdblocks corruption as below:
> > > >
> > > > Phase 1 - find and verify superblock...
> > > > Phase 2 - using internal log
> > > > - zero log...
> > > > - scan filesystem freespace and inode maps...
> > > > sb_fdblocks 14538692, counted 14669764
> > > > - found root inode chunk
> > > > Phase 3 - for each AG...
> > > > ...
> > > >
> > > > And the count diff is always 14669764 - 14538692 = 131072 (128k). The
> > > > XFS in question was formated with "-m rmapbt=1 -b 1k" option.
I hit this corruption again today in my fstests release testing, and it
reminded me this old thread :)
...
> > >
> > > So maybe the solution is to revert this patch and see if generic/224
> > > still blows up when suint/swidth are set? I tried the steps given in
> > > your email from 18 Nov 2016 ("[BUG] dd doesn't return on ENOSPC and hang
> > > when fulfilling rmapbt XFS") with sunit=32,swidth=224 (numbers I
> > > entirely made up) and it ran just fine. I then ran it with the
> > > reproducer steps you outlined above, and that ran just fine too.
> > > I did not run the rest of xfstests.
> >
> > Reverting commit fd26a88093ba works for me, I can't reproduce the
> > sb_fdblocks accounting error nor the dd hang bug.
>
> <nod> I'll consider posting a revert patch for the post -rc1 fixes.
>
> But... merge window stuff comes first. :)
Is reverting commit fd26a88093ba still the plan? Maybe we can do it for
4.14.
Thanks,
Eryu
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
