All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Darrick J. Wong" <djwong@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Dave Chinner <david@fromorbit.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jeff Layton <jlayton@kernel.org>
Subject: Re: question about mapping_set_error when writeback fails?
Date: Wed, 2 Jun 2021 23:26:46 +0100	[thread overview]
Message-ID: <YLgFpqi63K/NMO2D@casper.infradead.org> (raw)
In-Reply-To: <20210602202756.GA26333@locust>

On Wed, Jun 02, 2021 at 01:27:56PM -0700, Darrick J. Wong wrote:
> In iomap_finish_page_writeback,
> 
> static void
> iomap_finish_page_writeback(struct inode *inode, struct page *page,
> 		int error, unsigned int len)
> {
> 	struct iomap_page *iop = to_iomap_page(page);
> 
> 	if (error) {
> 		SetPageError(page);
> 		mapping_set_error(inode->i_mapping, -EIO);
> 
> Why don't we pass error to mapping_set_error here?  If the writeback
> completion failed due to insufficient space (e.g. extent mapping btree
> expansion hit ENOSPC while trying to perform an unwritten extent
> conversion) then we set AS_EIO which causes fsync to return EIO instead
> of ENOSPC like you'd expect.

Hah, I noticed the same thing a few weeks ago and didn't get round to
asking about it yet.  I'm pretty sure we should pass the real error to
mapping_set_error().

I also wonder if we shouldn't support more of the errors from
blk_errors, like -ETIMEDOUT or -EILSEQ, but that's a different
conversation.

  reply	other threads:[~2021-06-02 22:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-02 20:27 question about mapping_set_error when writeback fails? Darrick J. Wong
2021-06-02 22:26 ` Matthew Wilcox [this message]
2021-06-03 18:02   ` Jeff Layton

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=YLgFpqi63K/NMO2D@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=david@fromorbit.com \
    --cc=djwong@kernel.org \
    --cc=hch@infradead.org \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@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.