Message-ID: <20200818172231.GU17456@casper.infradead.org>
Date:   Tue, 18 Aug 2020 18:22:31 +0100
From:   Matthew Wilcox <willy@...radead.org>
To:     linux-block@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Support for I/O to a bitbucket

One of the annoying things in the iomap code is how we handle
block-misaligned I/Os.  Consider a write to a file on a 4KiB block size
filesystem (on a 4KiB page size kernel) which starts at byte offset 5000
and is 4133 bytes long.

Today, we allocate page 1 and read bytes 4096-8191 of the file into
it, synchronously.  Then we allocate page 2 and read bytes 8192-12287
into it, again, synchronously.  Then we copy the user's data into the
pagecache and mark it dirty.  This is a fairly significant delay for
the user who normally sees the latency of a memcpy() now has to wait
for two non-overlapping reads to complete.

What I'd love to be able to do is allocate pages 1 & 2, copy the user
data into it and submit one read which targets:

0-903: page 1, offset 0, length 904
904-5036: bitbucket, length 4133
5037-8191: page 2, offset 942, length 3155

That way, we don't even need to wait for the read to complete.

I envisage block allocating a bitbucket page to support devices which
don't have native support for bitbucket descriptors.  We'd also need a
fallback path for devices which don't support whatever alignment the
I/O is happening at ... but the block layer already has support for
bounce-buffering, right?

Anyway, I don't have time to take on this work, but I thought I'd throw
it out in case anyone's looking for a project.  Or if it's a stupid idea,
someone can point out why.

Powered by blists - more mailing lists