在 2016年07月20日 19:35, Eric Blake 写道:
On 07/04/2016 07:49 AM, Peter Lieven wrote:Hi,the above commit: commit d05aa8bb4a8b6aa9a915ec5074fb12ae632d2323 Author: Eric Blake <ebl...@redhat.com> 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.
outgoing_v22.tar
Description: Unix tar archive