From: Hannes Reinecke <hare@suse.de>
To: Matthew Wilcox <willy@infradead.org>,
linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] synchronous readpage for buffer_heads
Date: Fri, 23 Oct 2020 08:22:07 +0200 [thread overview]
Message-ID: <25528b1a-7434-62cb-705a-7269d050bbc1@suse.de> (raw)
In-Reply-To: <20201022152256.GU20115@casper.infradead.org>
On 10/22/20 5:22 PM, Matthew Wilcox wrote:
> I'm working on making readpage synchronous so that it can actually return
> errors instead of futilely setting PageError. Something that's common
> between most of the block based filesystems is the need to submit N
> I/Os and wait for them to all complete (some filesystems don't support
> sub-page block size, so they don't have this problem).
>
> I ended up coming up with a fairly nice data structure which I've called
> the blk_completion. It waits for 'n' events to happen, then wakes the
> task that cares, unless the task has got bored and wandered off to do
> something else.
>
> block_read_full_page() then uses this data structure to submit 'n' buffer
> heads and wait for them to all complete. The fscrypt code doesn't work
> in this scheme, so I bailed on that for now. I have ideas for fixing it,
> but they can wait.
>
> Obviously this all needs documentation, but I'd like feedback on the
> idea before I do that. I have given it some light testing, but there
> aren't too many filesystems left that use block_read_full_page() so I
> haven't done a proper xfstests run.
>
Hmm. You are aware, of course, that hch et al are working on replacing
bhs with iomap, right?
So wouldn't it be more useful to concentrate on the iomap code, and
ensure that _that_ is working correctly?
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@suse.de +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
next prev parent reply other threads:[~2020-10-23 6:22 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-22 15:22 [RFC] synchronous readpage for buffer_heads Matthew Wilcox
2020-10-23 6:22 ` Hannes Reinecke [this message]
2020-10-23 11:42 ` 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=25528b1a-7434-62cb-705a-7269d050bbc1@suse.de \
--to=hare@suse.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@infradead.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).