| Message ID | 1464973388-15821-3-git-send-email-eblake@redhat.com |
|---|---|
| State | New |
| Headers | show |
Am 03.06.2016 um 19:03 hat Eric Blake geschrieben: > Not that we pass any flags during reads yet, but we may want to > support BDRV_REQ_FUA on reads in the future. So don't throw > away the input flags. > > Signed-off-by: Eric Blake <eblake@redhat.com> Do we want to pass flags to bdrv_co_do_copy_on_readv(), too? I guess we would use them for the preadv call there, but continue to use 0 as the pwritev flags. We may also want to introduce a .supported_read_flags, but perhaps this is not something to do in this patch. And we don't even use .supported_write_flags for drivers that have a native .bdrv_co_pwritev. Of course, that's even less related to this patch. I guess I should send a fix for that. Looks good otherwise. Kevin
On 06/07/2016 06:12 AM, Kevin Wolf wrote: > Am 03.06.2016 um 19:03 hat Eric Blake geschrieben: >> Not that we pass any flags during reads yet, but we may want to >> support BDRV_REQ_FUA on reads in the future. So don't throw >> away the input flags. >> >> Signed-off-by: Eric Blake <eblake@redhat.com> > > Do we want to pass flags to bdrv_co_do_copy_on_readv(), too? I guess we > would use them for the preadv call there, but continue to use 0 as the > pwritev flags. What about BDRV_REQ_MAY_UNMAP if bdrv_co_do_copy_on_readv() detects a block of zeroes? This just got a lot trickier, so I think my short-term solution is to just assert(!flags) and add a comment that whoever implements flags on read has to solve the issue at that time, so that I'm not stalling the rest of this series on thinking about things that don't matter yet. > > We may also want to introduce a .supported_read_flags, but perhaps this > is not something to do in this patch. Yeah, I think we'll want that, at the point where we start worrying about read flags. > And we don't even use > .supported_write_flags for drivers that have a native .bdrv_co_pwritev. > Of course, that's even less related to this patch. I guess I should send > a fix for that. Thanks.
diff --git a/block/io.c b/block/io.c index 81618b9..3c7b233 100644 --- a/block/io.c +++ b/block/io.c @@ -983,7 +983,7 @@ static int coroutine_fn bdrv_aligned_preadv(BlockDriverState *bs, /* Forward the request to the BlockDriver */ if (!bs->zero_beyond_eof) { - ret = bdrv_driver_preadv(bs, offset, bytes, qiov, 0); + ret = bdrv_driver_preadv(bs, offset, bytes, qiov, flags); } else { /* Read zeros after EOF */ int64_t total_sectors, max_nb_sectors; @@ -997,7 +997,7 @@ static int coroutine_fn bdrv_aligned_preadv(BlockDriverState *bs, max_nb_sectors = ROUND_UP(MAX(0, total_sectors - sector_num), align >> BDRV_SECTOR_BITS); if (nb_sectors < max_nb_sectors) { - ret = bdrv_driver_preadv(bs, offset, bytes, qiov, 0); + ret = bdrv_driver_preadv(bs, offset, bytes, qiov, flags); } else if (max_nb_sectors > 0) { QEMUIOVector local_qiov; @@ -1007,7 +1007,7 @@ static int coroutine_fn bdrv_aligned_preadv(BlockDriverState *bs, ret = bdrv_driver_preadv(bs, offset, max_nb_sectors * BDRV_SECTOR_SIZE, - &local_qiov, 0); + &local_qiov, flags); qemu_iovec_destroy(&local_qiov); } else {
Not that we pass any flags during reads yet, but we may want to support BDRV_REQ_FUA on reads in the future. So don't throw away the input flags. Signed-off-by: Eric Blake <eblake@redhat.com> --- block/io.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)