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

2014-09-05 Thread Peter Lieven
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




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

2014-09-05 Thread ronnie sahlberg
Looks good to me.

(minor question is just why not let default max be 0x for both 10
and 16 CDBs ?)

On Fri, Sep 5, 2014 at 9:51 AM, Peter Lieven p...@kamp.de 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




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

2014-09-05 Thread Peter Lieven
Am 05.09.2014 um 19:05 schrieb ronnie sahlberg:
 Looks good to me.

 (minor question is just why not let default max be 0x 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 p...@kamp.de 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





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

2014-09-05 Thread ronnie sahlberg
Feel free to add a

Reviewed-by: Ronnie Sahlberg ronniesahlb...@gmail.com

to the patches.

On Fri, Sep 5, 2014 at 12:52 PM, Peter Lieven p...@kamp.de 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 0x 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 p...@kamp.de 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