qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] introduce max_transfer_length


From: ronnie sahlberg
Subject: Re: [Qemu-devel] [PATCH 0/4] introduce max_transfer_length
Date: Fri, 5 Sep 2014 14:22:39 -0700

Feel free to add a

Reviewed-by: Ronnie Sahlberg <address@hidden>

to the patches.

On Fri, Sep 5, 2014 at 12:52 PM, Peter Lieven <address@hidden> wrote:
> Am 05.09.2014 um 19:05 schrieb ronnie sahlberg:
>> Looks good to me.
>>
>> (minor question is just why not let default max be 0xffff for both 10
>> and 16 CDBs ?)
>
> You are right. I was looking at the technical limit, but in fact it doesn't
> make sense to have different limits. Its ridiculous to say, you wan't to
> do big I/O then you need a target thats bigger than 2TB ;-)
>
> Peter
>
>>
>> On Fri, Sep 5, 2014 at 9:51 AM, Peter Lieven <address@hidden> wrote:
>>> This series adds the basics for introducing a maximum transfer length
>>> to the block layer. Its main purpose is currently avoiding that
>>> a multiwrite_merge exceeds the max_xfer_len of an attached iSCSI LUN.
>>> This is a required bug fix.
>>>
>>> Discussed reporting of this maximum in the SCSI Disk Inquiry Emulation
>>> of the Block Limits VPD is currently not added as we do not import any
>>> of the other limits there. This has to be addresses in a seperate series.
>>>
>>> Peter Lieven (4):
>>>   BlockLimits: introduce max_transfer_length
>>>   block: immediate cancel oversized read/write requests
>>>   block/iscsi: set max_transfer_length
>>>   block: avoid creating oversized writes in multiwrite_merge
>>>
>>>  block.c                   |   23 +++++++++++++++++++++++
>>>  block/iscsi.c             |   12 ++++++++++--
>>>  include/block/block_int.h |    3 +++
>>>  3 files changed, 36 insertions(+), 2 deletions(-)
>>>
>>> --
>>> 1.7.9.5
>>>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]