[openstack-dev] May I run iscsiadm --op show & update 100 times?
honjo.rikimaru at po.ntt-tx.co.jp
Tue Oct 3 10:06:06 UTC 2017
On 2017/10/02 20:37, Gorka Eguileor wrote:
> On 02/10, Rikimaru Honjo wrote:
>> I'd like to discuss about the following bug of os-brick.
>> * os-brick's iscsi initiator unexpectedly reverts node.startup from "automatic" to "manual".
>> The important point of this bug is:
>> When os-brick initializes iscsi connections:
>> 1. os-brick will run "iscsiadm -m discovery" command if we use iscsi multipath.
> This only happens with a small number of cinder drivers, since most
> drivers try to avoid the discovery path due to the number of
> disadvantages it presents for a reliable deployment. The most notorious
> issue is that the path to the discovery portal on the attaching node is
> down you cannot attach the volume no matter how many of the other paths
> are up.
>> 2. os-brick will update node.startup values to "automatic" if we use iscsi.
>> 3. "iscsiadm -m discovery" command will recreate iscsi node repositories.
>> As a result, node.startup values of already attached volumes will be revert
>> to default(=manual).
>> Gorka Eguileor and I discussed how do I fix this bug.
>> Our idea is this:
>> 1. Confirm node.startup values of all the iscsi targets before running discovery.
>> 2. Re-update node.startup values of all the iscsi targets after running discovery.
>> But, I afraid that this operation will take a long time.
>> I ran showing & updating node.startup values 100 times for researching.
>> As a result, it took about 4 seconds.
>> When I ran 200 times, it took about 8 seconds.
>> I think this is a little long.
>> If we use multipath and attach 25 volumes, 100 targets will be created.
>> I think that updating 100 times is a possible use case.
>> How do you think about it?
>> Can I implement the above idea?
> The approach I proposed is on the review is valid, the flaw is in the
> specific implementation, you are doing 100 request where 4 would
> You don't need to do a request for each target-portal tuple, you only
> need to do 1 request per portal, which reduces the number of calls to
> iscsiadm from 100 to 4 in the case you mention.
> You can check all targets for an IP with:
> iscsiadm -m node -p IP
> This means that the performance hit from having 100 or 200 targets
> should be negligible.
I have one question.
I can see node.startup values by 1 request per portal as you said.
But, may I update values by 1 request per portal?
Updating values has been done by 1 request per target until now.
So I think my patch should update values in same way(=1 request per target).
>> This is correct behavior of iscsiadm.
>> Rikimaru Honjo
>> E-mail:honjo.rikimaru at po.ntt-tx.co.jp
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
E-mail:honjo.rikimaru at po.ntt-tx.co.jp
More information about the OpenStack-dev