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.

-- 
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.

Reply via email to