On 10/26/2010 03:29 AM, Andrea Sperelli wrote:
Hi Mike, thank you.
I did some test activities...
I really don't like the Linux+Lefthand behaviour.
On Lefthand node failure, Linux looses each path for each target of
the node. iSCSI initiator contatcts the LeftHand vip and
reestabilishes the session on another lefthand node.
I removed Mulitpath and configured bonding... It was not useful n this
I do not like it. It seems me less safe than iscsi + multipath. With
multipath the Linux server can never loose the path on only one node
san failure.
I cano not decide a different Lefthand configuration (two portal
without VIP), so I have to let this config on production.

The problem is that the iscsi/scsi layer will only retry a IO for this type of problem up to 5 times. So if you had to cycle through more than 5 portals you are screwed, or if the problem took more retries you are in trouble.

A workaround could be to use dm-multipath over your iscsi setup. Here you would just be using dm-multipath to force retries.

So if you lose a path
- iscsi would fail the IO to the dm-multipath driver
- dm-multipath would fail the single path and internally queue IO for the /etc/multipath.conf no_path_retry seconds. - iscsi would try the VIP address and get redirected to a new portal, and would login.
- dm-multipath would figure out the path is back up and start IO.
- iscsi would hopefully work this time. If not then we would repeat the steps above but the VIP addr would redirect us to a new address.

dm-multipath does not have a retry count, so you are not limited like if you were just using raw scsi/iscsi disk. Instead it has the no_path_retry paramter which puts an upper bound on how long you would internally queue IO when all paths are down.

You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to