All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Eryu Guan <eguan@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [BUG] dd doesn't return on ENOSPC and hang when fulfilling rmapbt XFS
Date: Thu, 17 Nov 2016 12:11:02 -0800	[thread overview]
Message-ID: <20161117201102.GK16813@birch.djwong.org> (raw)
In-Reply-To: <20161117173639.GJ16813@birch.djwong.org>

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.

--D

---
From: Darrick J. Wong <darrick.wong@oracle.com>
Subject: [PATCH] xfs: factor rmap btree size into the indlen calculations

When we're estimating the amount of space it's going to take to satisfy
a delalloc reservation, we need to include the space that we might need
to grow the rmapbt.  This helps us to avoid running out of space later
when _iomap_write_allocate needs more space than we reserved.  Eryu Guan
observed this happening on generic/224 when sunit/swidth were set.

Reported-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
 fs/xfs/libxfs/xfs_bmap.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
index b80a294..afedf96 100644
--- a/fs/xfs/libxfs/xfs_bmap.c
+++ b/fs/xfs/libxfs/xfs_bmap.c
@@ -49,6 +49,7 @@
 #include "xfs_rmap.h"
 #include "xfs_ag_resv.h"
 #include "xfs_refcount.h"
+#include "xfs_rmap_btree.h"
 
 
 kmem_zone_t		*xfs_bmap_free_item_zone;
@@ -190,8 +191,12 @@ xfs_bmap_worst_indlen(
 	int		maxrecs;	/* maximum record count at this level */
 	xfs_mount_t	*mp;		/* mount structure */
 	xfs_filblks_t	rval;		/* return value */
+	xfs_filblks_t   orig_len;
 
 	mp = ip->i_mount;
+
+	/* Calculate the worst-case size of the bmbt. */
+	orig_len = len;
 	maxrecs = mp->m_bmap_dmxr[0];
 	for (level = 0, rval = 0;
 	     level < XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK);
@@ -199,12 +204,20 @@ xfs_bmap_worst_indlen(
 		len += maxrecs - 1;
 		do_div(len, maxrecs);
 		rval += len;
-		if (len == 1)
-			return rval + XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) -
+		if (len == 1) {
+			rval += XFS_BM_MAXLEVELS(mp, XFS_DATA_FORK) -
 				level - 1;
+			break;
+		}
 		if (level == 0)
 			maxrecs = mp->m_bmap_dmxr[1];
 	}
+
+	/* Calculate the worst-case size of the rmapbt. */
+	if (xfs_sb_version_hasrmapbt(&mp->m_sb))
+		rval += 1 + xfs_rmapbt_calc_size(mp, orig_len) +
+				mp->m_rmap_maxlevels;
+
 	return rval;
 }

  reply	other threads:[~2016-11-17 20:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-17 16:35 [BUG] dd doesn't return on ENOSPC and hang when fulfilling rmapbt XFS Eryu Guan
2016-11-17 17:36 ` Darrick J. Wong
2016-11-17 20:11   ` Darrick J. Wong [this message]
2016-11-17 21:32     ` Dave Chinner
2016-11-17 23:55       ` [PATCH 0/4] xfs: fix rmapbt ENOSPC hangs Dave Chinner
2016-11-17 23:55         ` [PATCH 1/4] xfs: factor rmap btree size into the indlen calculations Dave Chinner
2016-11-17 23:55         ` [PATCH 2/4] xfs: add more AGF/AGFL manipulation tracepoints Dave Chinner
2016-11-17 23:55         ` [PATCH 3/4] xfs: hold AGF buffers over defer ops Dave Chinner
2016-11-18  0:53           ` Dave Chinner
2016-11-17 23:55         ` [PATCH 4/4] xfs: defer indirect delalloc rmap reservations Dave Chinner
2016-11-18  5:26     ` [BUG] dd doesn't return on ENOSPC and hang when fulfilling rmapbt XFS Eryu Guan
2016-11-18  5:46       ` Dave Chinner
2016-11-18  6:52         ` Eryu Guan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161117201102.GK16813@birch.djwong.org \
    --to=darrick.wong@oracle.com \
    --cc=eguan@redhat.com \
    --cc=linux-xfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.