On 30 Jul 2009 at 11:38, Mike Christie wrote: > > Mike Christie wrote: > > Hannes Reinecke wrote: > >> As per RFC5048 we cannot blindly assume that FastAbort is used, > >> but rather have to negotiate it with the target. And only when > >> the negotiation has been successful we can switch it on. > >> > > > > What targets have you found this to work with? > > > > The open-iscsi fast abort setting was implemented before the RFC even > > existed because targets the RFC did not exist yet so targets did not > > Actually that might not be true. It might have been around the same time. > > > > negotiate for it. > > > > A lot will want it without asking for it. > > > > I am not sure the rfc fastabort is the same as our workaround > fastabort. Does the rfc one apply to the abort tasks, or just the ones > mentioned in the rfc (the multi task ones)? The open-iscsi one applies > to all. We also do not do not handle the async event in 8.1 for 5048.
On page 14: c. MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1. On page 15: d. MUST send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on: On page 23: 8. iSCSI PDUs 8.1. Asynchronous Message This section defines additional semantics for the Asynchronous Message PDU defined in Section 10.9 of [RFC3720] using the same conventions. The following new legal value for the AsyncEvent is defined: 5: all active tasks for LU with a matching LUN field in the Async Message PDU are being terminated. The receiving initiator iSCSI layer MUST respond to this Message by taking the following steps in order. > > The open-iscsi fastabort is a hack because half of targets I hit did one > thing and half did the other, and I could not contact a lot of vendors. My strategy usually is to implement the standard correctly, then see how well others work with it. Occasionally it turn out the standard is wrong or misleading, but that's another problem. > I think we might still need this. However, I will try to rerun some > tests on the targets I have to here with updated firmware to check what > is up and maybe we can remove it or maybe we can get in touch with more > target vendors this time. > > If we end up with both the open-iscsi fastabort and the rfc fastabort, > we need the async event handling, and we have to rename the open-iscsi > config values. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
