From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>, darrick.wong@oracle.com
Cc: linux-btrfs@vger.kernel.org, fdmanana@gmail.com,
linux-fsdevel@vger.kernel.org, hch@lst.de
Subject: Re: [PATCH 0/3] Transient errors in Direct I/O
Date: Wed, 10 Jun 2020 13:31:55 +0800 [thread overview]
Message-ID: <3e11c9ae-15c5-c52a-2e8a-14756a5ef967@gmx.com> (raw)
In-Reply-To: <20200605204838.10765-1-rgoldwyn@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 1289 bytes --]
On 2020/6/6 上午4:48, 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" ;)
>
> With mixed buffered and direct writes in btrfs, the pages may not be
> released the extent may be locked in the ordered extents cleanup thread,
I'm wondering can we handle this case in a different way.
In fact btrfs has its own special handling for invalidating pages.
Btrfs will first look for any ordered extents covering the page, finish
the ordered extent manually, then invalidate the page.
I'm not sure why invalidate_inode_pages2_range() used in dio iomap code
does not use the fs specific invalidatepage(), but only do_lander_page()
then releasepage().
Shouldn'y we btrfs implement the lander_page() to handle ordered extents
properly?
Or is there any special requirement?
Thanks,
Qu
> which must make changes to the btrfs trees. In case of btrfs, if it is
> possible to wait, depending on the memory flags passed, wait for extent
> bit to be cleared so direct I/O is executed so there is no need to
> fallback to buffered I/O.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-06-10 5:32 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
2020-06-11 14:13 ` Goldwyn Rodrigues
2020-06-10 5:31 ` Qu Wenruo [this message]
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=3e11c9ae-15c5-c52a-2e8a-14756a5ef967@gmx.com \
--to=quwenruo.btrfs@gmx.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=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 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).