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. 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. 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
