On Mon, 2013-10-07 at 06:03 +0200, Thomas Glanzmann wrote: > Hello Doug, > > * Douglas Gilbert <dgilb...@interlog.com> [2013-10-07 00:58]: > > Great, another one working.
(CC'ing Hannes) > > BTW list_id=0 has a special meaning in some context > > (buried deep in T10 documents: spc4r36j.pdf). That is > > probably why Hannes Reinecke defaulted that list_id to > > 1. I could understand the target XCOPY implementation > > only accepting one xcopy sequence at a time, but why > > restrict it to list_id=0 ? A question for NaB ... > > Nab, do you have any input for us? > It was my original understanding that when OPERATING_PARAMETERS is reporting SNLID=1 (Supports No ListID), the initiator is expected to send EXTENDED_COPY parameter lists with ListID Usage 11b + ListID=0. Since we're ignoring the value of ListID for now anyways, I agree that it doesn't make much sense to fail for a non zero value here.. However, the main concern that made me add this check to begin with was the case with ListID Usage 00b + 10b, where the copy server is expected to keep a per I_T list of in-use ListIDs, and return CHECK_CONDITION + ILLEGAL REQUEST/OPERATION IN PROGRESS for a ListID for a copy sequence already in progress. Given that don't have this per I_T list that tracks ListIDs yet, it seemed wrong at the time to allow non zero ListIDs to be processed.. ;) Also, it's worth mentioning that the target XCOPY implementation does in fact support multiple copy sequences per device at a time, and there is currently no hard limit enforced for the number of copies, aside from the normal fabric dependent NodeACL queue_depth, et al. OPERATING PARAMETERS is currently reporting 1 for TOTAL CONCURRENT COPIES and MAXIMUM CONCURRENT COPIES, and I'll likely be adding a device attribute to control this depth, and enforce it's usage for v3.13 code. --nab -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
