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