All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Eryu Guan <eguan@redhat.com>,
	linux-xfs@vger.kernel.org
Subject: Re: [BUG] xfs/109 crashed 2k block size reflink enabled XFS
Date: Mon, 5 Dec 2016 11:05:08 -0800	[thread overview]
Message-ID: <20161205190508.GA2995@infradead.org> (raw)
In-Reply-To: <20161205182802.GB8436@birch.djwong.org>

On Mon, Dec 05, 2016 at 10:28:02AM -0800, Darrick J. Wong wrote:
> Hmm.  Purely speculating here (I haven't yet been able to reproduce it)
> but I wonder if we're nearly out of space, fdblocks is still large
> enough that we can start delalloc reservations, but something is
> stealing blocks out of the AGs such that when we go to look for one
> there aren't any (or the per AG reservation denies it).
> 
> Does it happen if rmapbt=0 ?  Since xfs/109 isn't doing any CoW, it's
> possible that this could be another symptom of the bug where we reserve
> all the bmap+rmap blocks we need via indlen, but discard the entire
> reservation in the transaction roll that happens before we start the
> rmap update, which effectively means we're allocating space that we
> didn't previously reserve...

I'm pretty sure it's something like that, but I don't think rmap
needs to be in the game - at least my customer report does not have rmap
enabled.

> I suppose you could constrict the reflink exception thing further by
> passing bma->flags to xfs_bmap_extents_to_btree and only allowing the
> ENOSPC retry if XFS_BMAPI_REMAP is set.

Well, we assert on having an allocation even without that exception,
so I'm not sure that would help us - it's just an oddity I noticed
while looking at the code.

  reply	other threads:[~2016-12-05 19:05 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-05  9:21 [BUG] xfs/109 crashed 2k block size reflink enabled XFS Eryu Guan
2016-12-05 12:45 ` Christoph Hellwig
2016-12-05 14:39 ` Christoph Hellwig
2016-12-05 15:36   ` Christoph Hellwig
2016-12-05 18:28     ` Darrick J. Wong
2016-12-05 19:05       ` Christoph Hellwig [this message]
2016-12-06  6:37       ` Eryu Guan
2016-12-06 14:45       ` Christoph Hellwig
2016-12-06 15:19         ` Brian Foster
2016-12-06 18:14           ` Darrick J. Wong
2016-12-07  3:49         ` Darrick J. Wong
2016-12-07  7:18           ` Christoph Hellwig
2016-12-07 17:40             ` Christoph Hellwig
2016-12-08  6:35               ` Darrick J. Wong
2016-12-08 14:30                 ` Christoph Hellwig
2016-12-06 13:48 ` Christoph Hellwig
2016-12-06 15:24   ` Eryu Guan
2016-12-06 16:31     ` 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=20161205190508.GA2995@infradead.org \
    --to=hch@infradead.org \
    --cc=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.