Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
* Support for I/O to a bitbucket
@ 2020-08-18 17:22 Matthew Wilcox
  2020-09-07  0:56 ` Dave Chinner
  0 siblings, 1 reply; 2+ messages in thread
From: Matthew Wilcox @ 2020-08-18 17:22 UTC (permalink / raw)
  To: linux-block; +Cc: linux-kernel, linux-fsdevel

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-07  0:56 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-18 17:22 Support for I/O to a bitbucket Matthew Wilcox
2020-09-07  0:56 ` Dave Chinner

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).