Re: [BUG] dd doesn't return on ENOSPC and hang when fulfilling rmapbt XFS

[Eryu Guan <eguan@redhat.com>]

On Fri, Nov 18, 2016 at 04:46:20PM +1100, Dave Chinner wrote:
> On Fri, Nov 18, 2016 at 01:26:33PM +0800, Eryu Guan wrote:
> > On Thu, Nov 17, 2016 at 12:11:02PM -0800, Darrick J. Wong wrote:
> > > On Thu, Nov 17, 2016 at 09:36:39AM -0800, Darrick J. Wong wrote:
> > > > On Fri, Nov 18, 2016 at 12:35:15AM +0800, Eryu Guan wrote:
> > > > > Hi all,
> > > > > 
> > > > > I hit a test hang in generic/224 when testing rmapbt enabled XFS on a
> > > > > host that has non-zero sunit/swidth reported from underlying device. And
> > > > > I simplified the reproducer to the following script, and the hang can be
> > > > > reproduced on any host now.
> > > > > 
> > > > > -----
> > > > > #!/bin/bash
> > > > > 
> > > > > dev=/dev/sda5
> > > > > mnt=/mnt/xfs
> > > > > 
> > > > > mkfs -t xfs -m rmapbt=1 -d agcount=8,size=1g -f $dev
> > > > 
> > > > Hm.  I formatted with:
> > > > mkfs.xfs -m rmapbt=1 -d sunit=4096,swidth=40960 -f /dev/sdf
> > > > 
> > > > (made up sunit numbers just to see how whacky it could get)
> > > > 
> > > > and got a different hang instead.  It looks like we are unable to
> > > > allocate any blocks to the bmbt and various things blow up from
> > > > there.  Will go retry with tracepoints on to see if we're running
> > > > out of AG reservation or if we're really out of disk blocks or what.
> > > > 
> > > > Crash message attached at the end.
> > > 
> > > Hm.  Looking at the indlen calculations, I see that we don't include the
> > > space that the rmapbt might need to store all the reverse mappings.  I
> > > think this is a problem, since we decline delalloc reservations if (len
> > > + indlen) > fdblocks, but we potentially end up using more than indlen
> > > blocks to map len blocks into the file, so the allocator goes nuts.
> > > 
> > > Eryu, does the following patch fix the problem you see?  I ran your
> > > reproducer and mine and it fixed the problem in both cases.  I didn't
> > > observe any issues running generic/224 either.
> > 
> > I applied your patch (and only your patch, patches posted by Dave were
> > not included) on top of 4.9-rc5 kernel, and it passed my simplified
> > reproducer, but still failed generic/224 with
> > 
> > MKFS_OPTIONS="-b size=4k -m crc=1,rmapbt=1 -d agcount=8"
> > 
> > Not all the time, but easily to hit. And sysrq-w showed the same traces
> > as before.
> > 
> > SECTION       -- xfs_test
> > RECREATING    -- xfs on /dev/mapper/testvg-testlv1
> > FSTYP         -- xfs (non-debug)
> > PLATFORM      -- Linux/x86_64 ibm-x3550m3-05 4.9.0-rc5+
> > MKFS_OPTIONS  -- -f -f -b size=4k -m crc=1,rmapbt=1 -d agcount=8 /dev/mapper/testvg-testlv2
> > MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/mapper/testvg-testlv2 /mnt/testarea/scratch
> > 
> > generic/224 16s ...  <===== never return
> 
> My patchset does pass generic/224 here, but it fails lots of other tests
> because of an accounting problem I've not yet found.

I applied all four patches you posted on top of v.9-rc5 this time. And
generic/224 still failed my test (test hang).

> 
> SECTION       -- xfs
> FSTYP         -- xfs (debug)
> PLATFORM      -- Linux/x86_64 test2 4.9.0-rc4-dgc+
> MKFS_OPTIONS  -- -f -m rmapbt=1 -i sparse=1 /dev/sdg

Does appending "-d agcount=8" to MKFS_OPTIONS make any difference for
you? I cannot reproduce the hang either if I remove the agcount config.

Thanks,
Eryu