From: Dave Chinner <david@fromorbit.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 6/7] xfs: don't ENOSPC on writeback when punching holes
Date: Wed, 21 Nov 2018 08:00:54 +1100 [thread overview]
Message-ID: <20181120210054.GP19305@dastard> (raw)
In-Reply-To: <20181120162833.GA2470@infradead.org>
On Tue, Nov 20, 2018 at 08:28:33AM -0800, Christoph Hellwig wrote:
> On Tue, Nov 20, 2018 at 08:50:42PM +1100, Dave Chinner wrote:
> > > > because the writeback error of ENOSPC was being reported. We're
> > > > going to free that space, so we don't care if there was a ENOSPC
> > > > writeback error. So ignore ENOSPC errors and punch anyway.
> > >
> > > How do even get -ENOSPC back from writeback? It seems like we have
> > > a much worse root cause lingering here.
> >
> > It hammered ENOSPC pretty hard - I think it had consumed the entire
> > reserve pool and that can causes allocation transaction reservations
> > in xfs_iomap_write_allocate() to return ENOSPC even if we've got a
> > reservation for the data extents being allocated.
>
> Well, that means we do have a problem somewhere in our accounting,
> as writeback should not run into ENOSPC.
Unwritten extent conversion consumes unreserved space when it splits
the BMBT and does all the other btree updates. If we do enough of
them at ENOSPC, we can consume the entire reservation pool.
In this case, I was creating a 25 million extent file using extent
size hints to try to get the number of extents down. It actually
resulted in the number of extents going up, because most of the
extents weren't fully written. IOWs, there was a /lot/ of partial
unwritten extent conversion going on in a very big extent tree.
> > This doesn't happen very often in the real world, but if it does we
> > need operations like punch to work to be able to free space and
> > get us out of that hole...
>
> I'm ok(-ish) with the patch, but I wish we could also sort out the
> root cause..
Yeah, it's not great, but it did mean I didn't have to mkfs the
filesystem to get out of trouble. mount/unmount doesn't fix a
depleted reserve pool, only freeing space will do that, and we
should be able to punch space out of a file when at ENOSPC...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2018-11-21 7:32 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-19 21:04 [PATCH 0/7] xfs: various fixes for 4.20 Dave Chinner
2018-11-19 21:04 ` [PATCH 1/7] xfs: zero length symlinks are not valid Dave Chinner
2018-11-20 8:12 ` Christoph Hellwig
2018-11-20 13:44 ` Brian Foster
2018-11-20 21:19 ` Dave Chinner
2018-11-21 12:01 ` Brian Foster
2018-11-19 21:04 ` [PATCH 2/7] xfs: uncached buffer tracing needs to print bno Dave Chinner
2018-11-20 8:12 ` Christoph Hellwig
2018-11-20 22:46 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 3/7] xfs: fix transient reference count error in xfs_buf_resubmit_failed_buffers Dave Chinner
2018-11-20 8:13 ` Christoph Hellwig
2018-11-20 22:48 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 4/7] xfs: finobt AG reserves don't consider last AG can be a runt Dave Chinner
2018-11-20 8:14 ` Christoph Hellwig
2018-11-20 22:49 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 5/7] xfs: extent shifting doesn't fully invalidate page cache Dave Chinner
2018-11-20 8:18 ` Christoph Hellwig
2018-11-20 22:53 ` Darrick J. Wong
2018-11-19 21:04 ` [PATCH 6/7] xfs: don't ENOSPC on writeback when punching holes Dave Chinner
2018-11-20 8:20 ` Christoph Hellwig
2018-11-20 9:50 ` Dave Chinner
2018-11-20 16:28 ` Christoph Hellwig
2018-11-20 21:00 ` Dave Chinner [this message]
2018-11-21 18:09 ` Darrick J. Wong
2018-11-22 2:31 ` Dave Chinner
2018-11-19 21:04 ` [PATCH 7/7] xfs: flush removing page cache in xfs_reflink_remap_prep Dave Chinner
2018-11-20 8:32 ` Christoph Hellwig
2018-11-20 22:56 ` Darrick J. Wong
2018-11-20 6:36 ` [PATCH 8/7] xfs: delalloc -> unwritten COW fork allocation can go wrong Dave Chinner
2018-11-20 13:45 ` Brian Foster
2018-11-20 16:33 ` Christoph Hellwig
2018-11-20 21:08 ` Dave Chinner
2018-11-20 16:32 ` Christoph Hellwig
2018-11-20 22:58 ` Darrick J. Wong
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=20181120210054.GP19305@dastard \
--to=david@fromorbit.com \
--cc=hch@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).