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
