linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Goldwyn Rodrigues <rgoldwyn@suse.de>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, darrick.wong@oracle.com
Subject: Re: [PATCH] iomap: return partial I/O count on error in direct I/O
Date: Mon, 17 Feb 2020 07:44:17 -0600	[thread overview]
Message-ID: <20200217134417.bxdw4yex5ky44p57@fiona> (raw)
In-Reply-To: <20200217131752.GA14490@infradead.org>

On  5:17 17/02, Christoph Hellwig wrote:
> On Thu, Feb 13, 2020 at 01:25:03PM -0600, Goldwyn Rodrigues wrote:
> > From: Goldwyn Rodrigues <rgoldwyn@suse.com>
> > 
> > In case of a block device error, iomap code returns 0 as opposed to
> > the amount of submitted I/O, which may have completed before the
> > error occurred. Return the count of submitted I/O for correct
> > accounting.
> 
> Haven't we traditionally failed direct I/O syscalls that don't fully
> complete and never supported short writes (or reads)?

Yes, but I think that decision should be with the filesystem what to do
with it and not the iomap layer.

The reason we need this patch for btrfs is that we need to account for
updating the allocations. iomap_end() returns written as zero while
iomap_dio_rw loop has submitted part of the I/O. So btrfs has no idea
as to how much has been submitted before the failure and how much of
the allocation to update.

This was exhibited by generic/250 in some of the runs where it fails the
underlying storage.

-- 
Goldwyn

  reply	other threads:[~2020-02-17 13:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-13 19:25 [PATCH] iomap: return partial I/O count on error in direct I/O Goldwyn Rodrigues
2020-02-17 13:17 ` Christoph Hellwig
2020-02-17 13:44   ` Goldwyn Rodrigues [this message]
2020-02-17 14:02     ` Christoph Hellwig
2020-02-19 20:31       ` Goldwyn Rodrigues

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=20200217134417.bxdw4yex5ky44p57@fiona \
    --to=rgoldwyn@suse.de \
    --cc=darrick.wong@oracle.com \
    --cc=hch@infradead.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 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).