Mike Christie wrote: > Jeremy Linton wrote: >> On Wednesday 06 December 2006 17:42, Jeremy Linton wrote: >>> On Wednesday 06 December 2006 16:50, Mike Christie wrote: >>>>> For iscsi, we could negotiate a value like MaxBurstLength which says >>>>> don't send commands with a payload larger than that size. I would guess >>>>> other transports have something similar. We have to check or make sure >>> ... >>> >>>> Oh yeah the exception I am thinking about may not be max sectors exactly >>>> but something close like iscsi's MaxBurstLength limit. Maybe iscsi LLDs >>>> are supposed to be translating that iscsi limit to max_sectors in which >>>> case we are talking about the same thing. For this limit we do not want >>> Sort of off topic, but the iSCSI MaxBurstLength doesn't set the max >>> transfer size, it simply is the amount of data that can be sent without a >>> R2T. If the transfer is larger then you have to wait for the R2T. In >>> practice it ends up controlling the _minimum_ amount of buffer space that >>> needs to be available _before_ the transfer starts, otherwise performace >>> sucks. >> Whops, Slight clarification, the MaxBurstLength is the max sent between >> R2T's >> what I described above is closer to the FirstBurstLength. What you guys are > > I should have clarified this would have been a workaround for some bad > targets, but I hoped could be more useful for other transports that > needed it for valid reasons. > > The MaxBurstLength length limits what can be transferred in sequence of > data-in pdus _or_ like you describe a solicited data out sequence, > doesn't it (see section 12.13)? We are more concerned with the data-in > sequence here. If we have a READ of 1048576 bytes and a > MaxBurstLength=524288 some targets were getting confused and instead of > splitting up the transfer into multiple sequences it would assume there > could be one sequence. So for those targets the MaxBurstLength becomes > the max we can read and targets do fun things like drop connections if > we send them something larger. > > Oh the flip side, targets also end up sending us more than > MaxBurstLength bytes between r2ts.
And actually, I think there was a target that bugged out when we tried to send it a WRITE that was larger than MaxBurstLength. I do not remember though. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
