From: Dave Chinner <david@fromorbit.com>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: darrick.wong@oracle.com, linux-btrfs@vger.kernel.org,
fdmanana@gmail.com, linux-fsdevel@vger.kernel.org, hch@lst.de,
linux-xfs@vger.kernel.org
Subject: Re: [PATCH 0/3] Transient errors in Direct I/O
Date: Wed, 10 Jun 2020 15:05:10 +1000 [thread overview]
Message-ID: <20200610050510.GL2040@dread.disaster.area> (raw)
In-Reply-To: <20200610025900.GA2005@dread.disaster.area>
On Wed, Jun 10, 2020 at 12:59:00PM +1000, Dave Chinner wrote:
> [ Please cc the XFS list on XFS and iomap infrastructure changes.]
>
> On Fri, Jun 05, 2020 at 03:48:35PM -0500, Goldwyn Rodrigues wrote:
> > In current scenarios, for XFS, it would mean that a page invalidation
> > would end up being a writeback error. So, if iomap returns zero, fall
> > back to biffered I/O. XFS has never supported fallback to buffered I/O.
> > I hope it is not "never will" ;)
>
> I wouldn't say "never", but we are not going to change XFS behaviour
> because btrfs has a page invalidation vs DIO bug in it...
Let me point out a specific "oh shit, I didn't think of that" sort
of problem that your blind fallback to buffered IO causes. Do this
via direct IO:
pwritev2(RWF_NOWAIT)
now have it fail invalidation in the direct IO path and fallback to
buffered write. What does buffered write do with it?
if (iocb->ki_flags & IOCB_NOWAIT)
return -EOPNOTSUPP;
Yup, userspace gets a completely spurious and bogus -EOPNOTSUPP
error to pwritev2() because some 3rd party is accessing the same
file via mmap or buffered IO.
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2020-06-10 5:34 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-05 20:48 [PATCH 0/3] Transient errors in Direct I/O Goldwyn Rodrigues
2020-06-05 20:48 ` [PATCH 1/3] iomap: dio Return zero in case of unsuccessful pagecache invalidation Goldwyn Rodrigues
2020-06-06 3:13 ` Matthew Wilcox
2020-06-05 20:48 ` [PATCH 2/3] btrfs: Wait for extent bits to release page Goldwyn Rodrigues
2020-06-08 10:20 ` Filipe Manana
2020-06-08 12:13 ` Goldwyn Rodrigues
2020-06-05 20:48 ` [PATCH 3/3] xfs: fallback to buffered I/O if direct I/O is short Goldwyn Rodrigues
2020-06-10 2:59 ` [PATCH 0/3] Transient errors in Direct I/O Dave Chinner
2020-06-10 5:05 ` Dave Chinner [this message]
2020-06-11 14:13 ` Goldwyn Rodrigues
2020-06-10 5:31 ` Qu Wenruo
2020-06-11 14:11 ` Goldwyn Rodrigues
2020-06-12 12:56 ` Qu Wenruo
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=20200610050510.GL2040@dread.disaster.area \
--to=david@fromorbit.com \
--cc=darrick.wong@oracle.com \
--cc=fdmanana@gmail.com \
--cc=hch@lst.de \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=rgoldwyn@suse.de \
/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.