qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] block/backup-top: fix flags handling
@ 2020-01-31 18:48 Vladimir Sementsov-Ogievskiy
  2020-01-31 19:38 ` Eric Blake
  0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2020-01-31 18:48 UTC (permalink / raw)
  To: qemu-block; +Cc: kwolf, vsementsov, qemu-devel, mreitz

backup-top "supports" write-unchanged, by skipping CBW operation in
backup_top_co_pwritev. But it forgets to do the same in
backup_top_co_pwrite_zeroes, as well as declare support for
BDRV_REQ_WRITE_UNCHANGED.

Fix this, and, while being here, declare also support for flags
supported by source child.

Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
---
 block/backup-top.c | 28 ++++++++++++++++++----------
 1 file changed, 18 insertions(+), 10 deletions(-)

diff --git a/block/backup-top.c b/block/backup-top.c
index 9aed2eb4c0..0e28fecc21 100644
--- a/block/backup-top.c
+++ b/block/backup-top.c
@@ -48,11 +48,17 @@ static coroutine_fn int backup_top_co_preadv(
 }
 
 static coroutine_fn int backup_top_cbw(BlockDriverState *bs, uint64_t offset,
-                                       uint64_t bytes)
+                                       uint64_t bytes, BdrvRequestFlags flags)
 {
     BDRVBackupTopState *s = bs->opaque;
-    uint64_t end = QEMU_ALIGN_UP(offset + bytes, s->bcs->cluster_size);
-    uint64_t off = QEMU_ALIGN_DOWN(offset, s->bcs->cluster_size);
+    uint64_t off, end;
+
+    if (flags & BDRV_REQ_WRITE_UNCHANGED) {
+        return 0;
+    }
+
+    off = QEMU_ALIGN_DOWN(offset, s->bcs->cluster_size);
+    end = QEMU_ALIGN_UP(offset + bytes, s->bcs->cluster_size);
 
     return block_copy(s->bcs, off, end - off, NULL);
 }
@@ -60,7 +66,7 @@ static coroutine_fn int backup_top_cbw(BlockDriverState *bs, uint64_t offset,
 static int coroutine_fn backup_top_co_pdiscard(BlockDriverState *bs,
                                                int64_t offset, int bytes)
 {
-    int ret = backup_top_cbw(bs, offset, bytes);
+    int ret = backup_top_cbw(bs, offset, bytes, 0);
     if (ret < 0) {
         return ret;
     }
@@ -71,7 +77,7 @@ static int coroutine_fn backup_top_co_pdiscard(BlockDriverState *bs,
 static int coroutine_fn backup_top_co_pwrite_zeroes(BlockDriverState *bs,
         int64_t offset, int bytes, BdrvRequestFlags flags)
 {
-    int ret = backup_top_cbw(bs, offset, bytes);
+    int ret = backup_top_cbw(bs, offset, bytes, flags);
     if (ret < 0) {
         return ret;
     }
@@ -84,11 +90,9 @@ static coroutine_fn int backup_top_co_pwritev(BlockDriverState *bs,
                                               uint64_t bytes,
                                               QEMUIOVector *qiov, int flags)
 {
-    if (!(flags & BDRV_REQ_WRITE_UNCHANGED)) {
-        int ret = backup_top_cbw(bs, offset, bytes);
-        if (ret < 0) {
-            return ret;
-        }
+    int ret = backup_top_cbw(bs, offset, bytes, flags);
+    if (ret < 0) {
+        return ret;
     }
 
     return bdrv_co_pwritev(bs->backing, offset, bytes, qiov, flags);
@@ -197,6 +201,10 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source,
 
     top->total_sectors = source->total_sectors;
     state = top->opaque;
+    top->supported_write_flags =
+        BDRV_REQ_WRITE_UNCHANGED | source->supported_write_flags;
+    top->supported_zero_flags =
+        BDRV_REQ_WRITE_UNCHANGED | source->supported_zero_flags;
 
     bdrv_ref(target);
     state->target = bdrv_attach_child(top, target, "target", &child_file, errp);
-- 
2.21.0



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

* Re: [PATCH] block/backup-top: fix flags handling
  2020-01-31 18:48 [PATCH] block/backup-top: fix flags handling Vladimir Sementsov-Ogievskiy
@ 2020-01-31 19:38 ` Eric Blake
  2020-02-03 13:32   ` Vladimir Sementsov-Ogievskiy
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Blake @ 2020-01-31 19:38 UTC (permalink / raw)
  To: Vladimir Sementsov-Ogievskiy, qemu-block; +Cc: kwolf, qemu-devel, mreitz

On 1/31/20 12:48 PM, Vladimir Sementsov-Ogievskiy wrote:
> backup-top "supports" write-unchanged, by skipping CBW operation in
> backup_top_co_pwritev. But it forgets to do the same in
> backup_top_co_pwrite_zeroes, as well as declare support for
> BDRV_REQ_WRITE_UNCHANGED.
> 
> Fix this, and, while being here, declare also support for flags
> supported by source child.
> 
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
>   block/backup-top.c | 28 ++++++++++++++++++----------
>   1 file changed, 18 insertions(+), 10 deletions(-)


> @@ -197,6 +201,10 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source,
>   
>       top->total_sectors = source->total_sectors;
>       state = top->opaque;
> +    top->supported_write_flags =
> +        BDRV_REQ_WRITE_UNCHANGED | source->supported_write_flags;
> +    top->supported_zero_flags =
> +        BDRV_REQ_WRITE_UNCHANGED | source->supported_zero_flags;

Elsewhere, in block/filter-compress.c we do:

     bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
         (BDRV_REQ_FUA & bs->file->bs->supported_write_flags);

     bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
         ((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
             bs->file->bs->supported_zero_flags);

That's slightly more robust (if the block layer adds new BDRV_REQ_ bits, 
we don't have to revisit filter-compress.c to decide if blindly exposing 
those bits breaks for some reason, but rahter DO have to amend the line 
to opt-in to supporting the new bits).  Whereas your code does NOT need 
editing if passing on the new bit is safe, but risks a subtle breakage 
if we forget to filter out the new bit when passing it on would be 
unsafe.  I tend to lean towards safety and opt-in over blind 
pass-through that works with the current set of defined bits, but not 
enough to withhold:

Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org



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

* Re: [PATCH] block/backup-top: fix flags handling
  2020-01-31 19:38 ` Eric Blake
@ 2020-02-03 13:32   ` Vladimir Sementsov-Ogievskiy
  0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Sementsov-Ogievskiy @ 2020-02-03 13:32 UTC (permalink / raw)
  To: Eric Blake, qemu-block; +Cc: kwolf, qemu-devel, mreitz

31.01.2020 22:38, Eric Blake wrote:
> On 1/31/20 12:48 PM, Vladimir Sementsov-Ogievskiy wrote:
>> backup-top "supports" write-unchanged, by skipping CBW operation in
>> backup_top_co_pwritev. But it forgets to do the same in
>> backup_top_co_pwrite_zeroes, as well as declare support for
>> BDRV_REQ_WRITE_UNCHANGED.
>>
>> Fix this, and, while being here, declare also support for flags
>> supported by source child.
>>
>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>> ---
>>   block/backup-top.c | 28 ++++++++++++++++++----------
>>   1 file changed, 18 insertions(+), 10 deletions(-)
> 
> 
>> @@ -197,6 +201,10 @@ BlockDriverState *bdrv_backup_top_append(BlockDriverState *source,
>>       top->total_sectors = source->total_sectors;
>>       state = top->opaque;
>> +    top->supported_write_flags =
>> +        BDRV_REQ_WRITE_UNCHANGED | source->supported_write_flags;
>> +    top->supported_zero_flags =
>> +        BDRV_REQ_WRITE_UNCHANGED | source->supported_zero_flags;
> 
> Elsewhere, in block/filter-compress.c we do:
> 
>      bs->supported_write_flags = BDRV_REQ_WRITE_UNCHANGED |
>          (BDRV_REQ_FUA & bs->file->bs->supported_write_flags);
> 
>      bs->supported_zero_flags = BDRV_REQ_WRITE_UNCHANGED |
>          ((BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK) &
>              bs->file->bs->supported_zero_flags);
> 

I've looked at this too, but didn't understand, why we need it. Now with your description, I see that this make sense. I'll resend with same pattern, thanks.

> That's slightly more robust (if the block layer adds new BDRV_REQ_ bits, we don't have to revisit filter-compress.c to decide if blindly exposing those bits breaks for some reason, but rahter DO have to amend the line to opt-in to supporting the new bits).  Whereas your code does NOT need editing if passing on the new bit is safe, but risks a subtle breakage if we forget to filter out the new bit when passing it on would be unsafe.  I tend to lean towards safety and opt-in over blind pass-through that works with the current set of defined bits, but not enough to withhold:
> 
> Reviewed-by: Eric Blake <eblake@redhat.com>
> 


-- 
Best regards,
Vladimir


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

end of thread, other threads:[~2020-02-03 13:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-01-31 18:48 [PATCH] block/backup-top: fix flags handling Vladimir Sementsov-Ogievskiy
2020-01-31 19:38 ` Eric Blake
2020-02-03 13:32   ` Vladimir Sementsov-Ogievskiy

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