On Wed, Jul 1, 2015 at 3:41 PM, Craig Watson <craig.watson@xxxxxxxxxxxxxxxxxxx> wrote: > So, is it really a limitation in the hardware? .. or is it in the qla2xxx > driver? Does the qla2xxx driver not support chained scatter/gather lists? > > Since the removal of fabric_max_sectors et.al. how is this size limit > communicated to an initiator? From what I understood, the target front end > is going to reflect the limit of the back end storage. Right now what I > (and our customers) see is just a refusal to operate at large (> 4.9MB) > transfer sizes. At some write sizes there aren't even any error indications > on the target. The target just stops responding. This isn't a good thing. > It's better than crashing but not by much. Other sizes do seem to crash the > kernel which really isn't a good thing. The hardware really has the limitation that a single CTIO ("continue target IO") control block can only have 1200-something gather-scatter entries (which matches well with your 4.9 MB limit, given that each entry will typically be a 4KB page). However the fact that that limits the size of a SCSI command is of course in driver code. LIO can use multiple CTIOs to respond to a single SCSI command. It doesn't at the moment though. There is no way this is communicated to the initiator that I know of at the moment. I did not understand the "remove IO size limit" commits when they went in, but they definitely leave the target stack in a broken state WRT this type of issue. - R. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html