[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH v4 02/15] blkverify: set supported write/zero fl
From: |
Eric Blake |
Subject: |
Re: [Qemu-block] [PATCH v4 02/15] blkverify: set supported write/zero flags |
Date: |
Fri, 4 Aug 2017 10:23:08 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
On 08/01/2017 09:18 AM, Anton Nefedov wrote:
> Signed-off-by: Anton Nefedov <address@hidden>
> ---
> block/blkverify.c | 9 +++++++++
> 1 file changed, 9 insertions(+)
Basically, blkverify supports a flag if BOTH of its underlying files
also support the flag; if either side can't handle the flag, then we
fall back to emulation for both sides.
With more overhead, we COULD state that we support both bits if at least
one of the two underlying BDS supports the bit, and then emulate support
for the bit on the second BDS where it was lacking, so that at least the
first BDS doesn't suffer from the penalties of the fallbacks. But that
means duplicating the block layer fallback code in blkverify, which is
already something that we don't necessarily expect high performance from.
For FUA, failure to implement the bit merely means that we have more
device-wide flush calls (instead of per-transaction mini-flushes), but
the end data should be the same. But for MAY_UNMAP, I'm worried that we
may have situations where a plain BDS will create holes, while running
the same device paired through blkverify will fall back to slower
explicit zeroes. I'm wondering whether this will bite us, if we have
scenarios where the mere fact of trying to verify block device behavior
changes what behavior we are even verifying.
Thus, while I think the code change _looks_ okay, I'm not sure if it is
correct design-wise, nor whether it is 2.10 material.
> + bs->supported_write_flags = BDRV_REQ_FUA &
> + bs->file->bs->supported_write_flags &
> + s->test_file->bs->supported_write_flags;
> +
> + bs->supported_zero_flags =
> + (BDRV_REQ_FUA | BDRV_REQ_MAY_UNMAP) &
> + bs->file->bs->supported_zero_flags &
> + s->test_file->bs->supported_zero_flags;
> +
> ret = 0;
> fail:
> qemu_opts_del(opts);
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-block] [PATCH v4 08/15] qcow2: set inactive flag, (continued)
- [Qemu-block] [PATCH v4 07/15] qcow2: preallocation at image expand, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 04/15] block: treat BDRV_REQ_ALLOCATE as serialising, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 05/15] file-posix: support BDRV_REQ_ALLOCATE, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 06/15] block: support BDRV_REQ_ALLOCATE in passthrough drivers, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 09/15] qcow2: truncate preallocated space, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 02/15] blkverify: set supported write/zero flags, Anton Nefedov, 2017/08/01
- Re: [Qemu-block] [PATCH v4 02/15] blkverify: set supported write/zero flags,
Eric Blake <=
- [Qemu-block] [PATCH v4 03/15] block: introduce BDRV_REQ_ALLOCATE flag, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 11/15] qcow2: move is_zero() up, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 12/15] qcow2: skip writing zero buffers to empty COW areas, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 14/15] iotest 190: test BDRV_REQ_ALLOCATE, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 13/15] qcow2: allocate image space by-cluster, Anton Nefedov, 2017/08/01
- [Qemu-block] [PATCH v4 15/15] iotest 134: test cluster-misaligned encrypted write, Anton Nefedov, 2017/08/01