Re: [Bug 7026] CD/DVD burning with USB writer doesn't work

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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. The initiator just prints an error
and makes sure it does not go out of bounds because this is so common.
We have to handle lots of fun bugs in targets. I bet targets do lots of
weird things to handle our mess ups too :)

And a sequence does not necessarily mean one pdu so
MaxRecvDataSegmentLength does not matter in the discussion of max
request size here (as long as we are talking about good behaving targets
:)).

Sorry for the confusion.

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux