On 12/12/2014 12:30 PM, Mike Christie wrote: > On 12/11/2014 01:53 PM, The Lee-Man wrote: >> Hi Mike: >> >> I have started working more with iscsiuio. >> >> I have discovered what I consider a bug in an error message printed >> during normal operation of iscsiadm that makes it seem like something >> bad happened. >> >> As you know, when performing discovery via the bnx2i transport and the >> iscsiuio daemon, the iscsiadm command tries to set up host parameters >> when a target is discovered. The iscsiadm command does this by sending a >> message to the iscsiuio daemon, who actually does the work in this case >> and then normally returns that information. >> >> But it looks like the design of iscsiuio is that it does not even try to >> set up the NIC it is using very first time its called. Instead, it >> initializes the NIC only when the first attempt to use it is received, >> while it returns EAGAIN to the caller. The protocol evidently is that >> the caller knows to retry. In this case, the iscsiadm code retries >> several times no matter what error is returned. In fact, the iscsiadm >> code being used translates all errors received from this attempt to talk >> to iscsiuio into an "INTERNAL_ERROR", and the communication is retried >> anyway. >> >> This translation is the only problem, IMHO, and resulted in these >> messages from iscsiadm, which are misleading (and poorly formatted): >> >> iscsiadm: Could not set host net params (err 29) >> >> iscsiadm: Connection to discovery portal 10.125.128.120 failed: >> internal error >> ... >> >> which becomes, with my patches: >> >> iscsiadm: Could not set host net params (err 29) >> iscsiadm: Connection to discovery portal 192.168.30.1 failed: operation >> failed but retry may succeed >> ... >> >> The "fix" is simple: in the case where iscsiuio returns EAGAIN, let it >> through. (And fix the error message printing so we don't core dump, of >> course.) >> >> I thought about a more aggressive fix, i.e. letting all return values >> from the communications attempt through, but I worried about fixing >> something that is not really broken and perhaps breaking something else. >> So, in the spirit of fixing just what is broken, I submit two patches: > > That is not how we do it. Just like in that other thread about the sysfs > scanning. We want to fix the root cause and also any issues that result > from it. > > Please just fix this properly. It is really silly that the user would > have to run this command twice to actually do discovery.
Hi Lee, I want to apologize for being a jerk above. The email is unprofessional. I value your submissions and help on this project. I have no excuse, and request that you please continue to help out and be part of this project Mike -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
