[PATCH 0/6] block: block-status cache for data regions

Max Reitz posted 6 patches 2 years, 10 months ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20210617155247.442150-1-mreitz@redhat.com
Maintainers: Peter Lieven <pl@kamp.de>, Fam Zheng <fam@euphon.net>, Paolo Bonzini <pbonzini@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>, Ronnie Sahlberg <ronniesahlberg@gmail.com>, Kevin Wolf <kwolf@redhat.com>, Eric Blake <eblake@redhat.com>, Max Reitz <mreitz@redhat.com>, Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
There is a newer version of this series
include/block/block_int.h | 21 ++++++++--
block.c                   |  2 +
block/file-posix.c        |  7 ++--
block/gluster.c           |  7 ++--
block/io.c                | 80 +++++++++++++++++++++++++++++++++++++--
block/iscsi.c             |  3 --
block/nbd.c               |  2 +-
7 files changed, 105 insertions(+), 17 deletions(-)
[PATCH 0/6] block: block-status cache for data regions
Posted by Max Reitz 2 years, 10 months ago
Hi,

We’ve already had two attempts at introducing a block-status cache for
data regions
(https://lists.gnu.org/archive/html/qemu-devel/2019-01/msg06451.html,
"file-posix: Cache lseek result for data regions";
https://lists.nongnu.org/archive/html/qemu-block/2021-02/msg00934.html,
"file-posix: Cache next hole"), both of which were local to file-posix.

I have a gitlab issue assigned to me
(https://gitlab.com/qemu-project/qemu/-/issues/307), so I suppose it’s
time for round three.

This series tries to address what I gathered from the reviews for both:
(1) We should try to have this cache in the general block layer for all
protocol drivers; (2) Just to be sure, we should have a mutex for it;
(3) External writers don’t matter if we just cache data regions, because
(for a protocol node) reporting a zero region as data isn’t fatal.

Patch 1 is clean-up, patch 2 is the main one, patches 3 to 6 make it
more useful: Some protocol drivers force-clamp the returned *pnum based
on the @bytes parameter, but that’s completely unnecessary, because
bdrv_co_block_status() will clamp the value, too.  It’s beneficial to
return as large a *pnum value as possible to bdrv_co_block_status(), so
our cache can be more effective.


Max Reitz (6):
  block: Drop BDS comment regarding bdrv_append()
  block: block-status cache for data regions
  block/file-posix: Do not force-cap *pnum
  block/gluster: Do not force-cap *pnum
  block/nbd: Do not force-cap *pnum
  block/iscsi: Do not force-cap *pnum

 include/block/block_int.h | 21 ++++++++--
 block.c                   |  2 +
 block/file-posix.c        |  7 ++--
 block/gluster.c           |  7 ++--
 block/io.c                | 80 +++++++++++++++++++++++++++++++++++++--
 block/iscsi.c             |  3 --
 block/nbd.c               |  2 +-
 7 files changed, 105 insertions(+), 17 deletions(-)

-- 
2.31.1