On 07/04/2016 07:49 AM, Peter Lieven wrote:
Hi,
the above commit:
commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323
Author: Eric Blake <address@hidden>
Date: Wed Jun 1 15:10:03 2016 -0600
block: Add .bdrv_co_pwrite_zeroes()
introduces a regression (at least for me).
The Limits from the iSCSI Block Limits VPD have no requirement of being
a power of two.
We use Dell Equallogic iSCSI SANs for instance. They have an internal
page size of 15MB. And
they advertise this page size as max_ws_len, opt_transfer_len and
opt_discard_alignment.
Since I don't have access to this device, let me double check: if you
put a breakpoint in iscsi.c:iscsi_refresh_limits(), can you dump the
contents of the struct iscsilun->bl? What is the block size of this
device (512, 4096, something else)?
Also, while the device is advertising that the optimal discard alignment
is 15M, that does not tell me the minimum granularity that it can
actually discard. Can you determine that value? That is, if I try to
discard only 1M, does that actually result in a 1M allocation hole, or
is it ignored? It sounds like qemu should be tracking 2 separate
values: the minimum discard granularity (I suspect this number is a
power of 2, at least the block size, and perhaps precisely equal to the
block size), and the maximum discard granularity that results in the
fewest/fastest discard of the entire device (not necessarily a power of
2). Or, maybe that merely means that qemu's pdiscard_alignment should
be the MINIMUM granularity, and NOT the non-power-of-2
iscsilun->bl.opt_unmap_gran.
Or put another way, I get that I can't discard more than 15M at a time.
But I highly suspect that I do not have to align my discard requests to
15M boundaries. That is, if the discard granularity is 1M, then in
qemu-io, 'discard 1M 15M' should result in a 15M hole, and should be no
different from the result of 'discard 1M 14M; discard 15M 1M'. But if
qemu sticks to pdiscard_alignment == iscsilun->bl.opt_unmap_gran of 15M,
then both operations mistakenly discard nothing (because it is not
aligned to a 15M boundary).
I think we cannot assert that that these alignments are a power of 2.
Optimal size not being a power of 2 is not a problem, but I still
suspect MINIMUM alignment is a power of 2, and I need to know how much
head and tail to discard in the new byte-based discard routines in order
to align requests up to the minimal discard alignment boundaries.