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