On Friday, December 12, 2014 12:26:00 PM UTC-8, Mike Christie wrote: > > 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 >
Mike: I apologize for taking it personally. No harm no foul. -- 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.
