Re: [Qemu-devel] Regression: block: Add .bdrv_co_pwrite_zeroes()

[wangweiwei <wangww.fnst@cn.fujitsu.com>]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

在 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 <eblake@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.
>
>



[-- Attachment #2: outgoing_v22.tar --]
[-- Type: application/x-tar, Size: 102400 bytes --]