From: Matthew Wilcox <willy@infradead.org>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
Kent Overstreet <kent.overstreet@gmail.com>
Subject: Re: [RFC] Better page cache error handling
Date: Wed, 24 Feb 2021 13:41:15 +0000 [thread overview]
Message-ID: <20210224134115.GP2858050@casper.infradead.org> (raw)
In-Reply-To: <20210224123848.GA27695@quack2.suse.cz>
On Wed, Feb 24, 2021 at 01:38:48PM +0100, Jan Kara wrote:
> > We allocate a page and try to read it. 29 threads pile up waiting
> > for the page lock in filemap_update_page(). The error returned by the
> > original I/O is shared between all 29 waiters as well as being returned
> > to the requesting thread. The next request for index.html will send
> > another I/O, and more waiters will pile up trying to get the page lock,
> > but at no time will more than 30 threads be waiting for the I/O to fail.
>
> Interesting idea. It certainly improves current behavior. I just wonder
> whether this isn't a partial solution to a problem and a full solution of
> it would have to go in a different direction? I mean it just seems
> wrong that each reader (let's assume they just won't overlap) has to retry
> the failed IO and wait for the HW to figure out it's not going to work.
> Shouldn't we cache the error state with the page? And I understand that we
> then also have to deal with the problem how to invalidate the error state
> when the block might eventually become readable (for stuff like temporary
> IO failures). That would need some signalling from the driver to the page
> cache, maybe in a form of some error recovery sequence counter or something
> like that. For stuff like iSCSI, multipath, or NBD it could be doable I
> believe...
That felt like a larger change than I wanted to make. I already have
a few big projects on my plate!
Also, it's not clear to me that the host can necessarily figure out when
a device has fixed an error -- certainly for the three cases you list
it can be done. I think we'd want a timer to indicate that it's worth
retrying instead of returning the error.
Anyway, that seems like a lot of data to cram into a struct page. So I
think my proposal is still worth pursuing while waiting for someone to
come up with a perfect solution.
next prev parent reply other threads:[~2021-02-24 13:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-05 16:11 [RFC] Better page cache error handling Matthew Wilcox
2021-02-24 12:38 ` Jan Kara
2021-02-24 13:41 ` Matthew Wilcox [this message]
2021-02-24 17:44 ` Jan Kara
2021-02-24 23:41 ` Andreas Dilger
2021-02-24 23:54 ` Matthew Wilcox
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=20210224134115.GP2858050@casper.infradead.org \
--to=willy@infradead.org \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=kent.overstreet@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).