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 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 <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 >>> >
