diff options
| author | Hanna Czenczek <hreitz@redhat.com> | 2023-02-27 11:47:24 +0100 |
|---|---|---|
| committer | Kevin Wolf <kwolf@redhat.com> | 2023-03-10 15:14:46 +0100 |
| commit | 1703eb1c27a6010ff33d5add2d76aadc9b2777bd (patch) | |
| tree | acd0f4c0d0842e9c8b9288687a037b27de529e1b /migration/vmstate.c | |
| parent | ee59483267de29056b5b2ee2421ef3844e5c9932 (diff) | |
| download | qemu-1703eb1c27a6010ff33d5add2d76aadc9b2777bd.zip qemu-1703eb1c27a6010ff33d5add2d76aadc9b2777bd.tar.gz qemu-1703eb1c27a6010ff33d5add2d76aadc9b2777bd.tar.bz2 | |
block/fuse: Let PUNCH_HOLE write zeroes
fallocate(2) says about PUNCH_HOLE: "After a successful call, subsequent
reads from this range will return zeros." As it is, PUNCH_HOLE is
implemented as a call to blk_pdiscard(), which does not guarantee this.
We must call blk_pwrite_zeroes() instead. The difference to ZERO_RANGE
is that we pass the `BDRV_REQ_MAY_UNMAP | BDRV_REQ_NO_FALLBACK` flags to
the call -- the storage is supposed to be unmapped, and a slow fallback
by actually writing zeroes as data is not allowed.
Closes: https://gitlab.com/qemu-project/qemu/-/issues/1507
Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
Message-Id: <20230227104725.33511-2-hreitz@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'migration/vmstate.c')
0 files changed, 0 insertions, 0 deletions