| Message ID | 20210812084148.14458-4-hreitz@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | block-status cache for data regions | expand |
On Thu, Aug 12, 2021 at 10:41:45AM +0200, Hanna Reitz wrote: > .bdrv_co_block_status() implementations are free to return a *pnum that > exceeds @bytes, because bdrv_co_block_status() in block/io.c will clamp > *pnum as necessary. > > On the other hand, if drivers' implementations return values for *pnum > that are as large as possible, our recently introduced block-status > cache will become more effective. > > So, make a note in block_int.h that @bytes is no upper limit for *pnum. > > Suggested-by: Eric Blake <eblake@redhat.com> > Signed-off-by: Hanna Reitz <hreitz@redhat.com> > Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> > --- > include/block/block_int.h | 9 +++++++++ > 1 file changed, 9 insertions(+) Reviewed-by: Eric Blake <eblake@redhat.com>
diff --git a/include/block/block_int.h b/include/block/block_int.h index 437d746733..5451f89b8d 100644 --- a/include/block/block_int.h +++ b/include/block/block_int.h @@ -348,6 +348,15 @@ struct BlockDriver { * clamped to bdrv_getlength() and aligned to request_alignment, * as well as non-NULL pnum, map, and file; in turn, the driver * must return an error or set pnum to an aligned non-zero value. + * + * Note that @bytes is just a hint on how big of a region the + * caller wants to inspect. It is not a limit on *pnum. + * Implementations are free to return larger values of *pnum if + * doing so does not incur a performance penalty. + * + * block/io.c's bdrv_co_block_status() will utilize an unclamped + * *pnum value for the block-status cache on protocol nodes, prior + * to clamping *pnum for return to its caller. */ int coroutine_fn (*bdrv_co_block_status)(BlockDriverState *bs, bool want_zero, int64_t offset, int64_t bytes, int64_t *pnum,