Hi,
is there any hope of working combination of MULTIPATH with FC !?
At the moment I am using raid option multipath but it's one way
street, when one FC connection dies it successfully switches onto
another FC connection but when that second dies aswell, mount point
is in a limbo, no switching back to first FC connection.
Any other solutions, patches ?!
--
Mario Miko?evi? (Mozgy)
mozgy at hinet dot hr
My favourite FUBAR ...
On 2002-01-14T12:33:01,
Mario Mikocevic <[email protected]> said:
> is there any hope of working combination of MULTIPATH with FC !?
Yes. QLogic's newest 2200 HBA can do that. I don't know whether that is a
possible solution for your problem though.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
> > is there any hope of working combination of MULTIPATH with FC !?
>
> Yes. QLogic's newest 2200 HBA can do that. I don't know whether that is a
> possible solution for your problem though.
To clarify: This solution is being pushed by IBM. Unless you have a FASt
array, you may not get help making it work from either IBM or Qlogic. You
also need the 5.x qlogic driver which you can download from the IBM website
(or from SuSE 7.3).
> At the moment I am using raid option multipath but it's one way
> street, when one FC connection dies it successfully switches onto
> another FC connection but when that second dies aswell, mount point is
> in a limbo, no switching back to first FC connection.
I've tested the qlogic and it will switch to the secondary and back again on a
FASt 200 HA.
Although it was designed to work with the LSI Symplicity-4 AVT technology
(which is what IBM FASt's OEM), there's a high degree of probability that it
will also work with any array that the MD multipath driver also works for, so
good luck.
James Bottomley
SteelEye Technology
James Bottomley wrote:
>
> > > is there any hope of working combination of MULTIPATH with FC !?
> >
> > Yes. QLogic's newest 2200 HBA can do that. I don't know whether that is a
> > possible solution for your problem though.
>
> To clarify: This solution is being pushed by IBM. Unless you have a FASt
> array, you may not get help making it work from either IBM or Qlogic. You
> also need the 5.x qlogic driver which you can download from the IBM website
> (or from SuSE 7.3).
the 5.x qlogic driver "needs some work" to not function properly though,
unfortionatly. But that's a work in progress.....
Lars Marowsky-Bree wrote:
> On 2002-01-14T12:33:01, Mario Mikocevic <[email protected]> said:
>
>
>> is there any hope of working combination of MULTIPATH with FC !?
>>
>
> Yes. QLogic's newest 2200 HBA can do that. I don't know whether that
> is a possible solution for your problem though.
>
The real question is when will Linux fully support multipath at the
CAM/block layer? I'd really like to be able to throw, say, four HBAs
into my system and have it use all of them simultaneously and not have
to spend all sorts of time trying to set up all 200+ LUNs that I have
available to me by hand. Think 200 LUNs presented * 4 HBAs * 4 paths at
the controller end per LUN. That's quite a bit of setup to me.
- Pete
On Mon, 2002-01-14 at 07:24, James Bottomley wrote:
> > > is there any hope of working combination of MULTIPATH with FC !?
> >
> > Yes. QLogic's newest 2200 HBA can do that. I don't know whether that is a
> > possible solution for your problem though.
>
> To clarify: This solution is being pushed by IBM. Unless you have a FASt
> array, you may not get help making it work from either IBM or Qlogic. You
> also need the 5.x qlogic driver which you can download from the IBM website
> (or from SuSE 7.3).
>
> > At the moment I am using raid option multipath but it's one way
> > street, when one FC connection dies it successfully switches onto
> > another FC connection but when that second dies aswell, mount point is
> > in a limbo, no switching back to first FC connection.
>
> I've tested the qlogic and it will switch to the secondary and back again on a
> FASt 200 HA.
>
> Although it was designed to work with the LSI Symplicity-4 AVT technology
> (which is what IBM FASt's OEM), there's a high degree of probability that it
> will also work with any array that the MD multipath driver also works for, so
> good luck.
>
I've been working with the multipath code. Trying to add functionality
to it. While I have not yet looked at this particular issue, if there
is interest I would be willing to see what can be done. I do not think
it would be a big deal to add the functionality to reactivate a dead
path. It should not be too hard to attempt to do so automatically.
On 2002-01-14T11:53:07,
Brian Beattie <[email protected]> said:
> I've been working with the multipath code. Trying to add functionality
> to it. While I have not yet looked at this particular issue, if there
> is interest I would be willing to see what can be done. I do not think
> it would be a big deal to add the functionality to reactivate a dead
> path. It should not be too hard to attempt to do so automatically.
It should only be tried on demand, or at least possible to configure it in
this way; more safe.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
On Mon, 2002-01-14 at 03:33, Mario Mikocevic wrote:
> Hi,
>
> is there any hope of working combination of MULTIPATH with FC !?
>
> At the moment I am using raid option multipath but it's one way
> street, when one FC connection dies it successfully switches onto
> another FC connection but when that second dies aswell, mount point
> is in a limbo, no switching back to first FC connection.
>
> Any other solutions, patches ?!
>
After analysing the current code in md/multipath and discussing it with
other here who have experience with multipath support I have come up
with the following approach.
When a path fails and there are no more good paths, an attempt will be
made complete the operation using each previously failed path untill the
operation succeds, or all know paths have been tried. If the operation
succeds, that path will be marked good.
When a operation is attempted and no good paths exist, the operation
will be attempted on each know path until success or all know paths are
tried.
Probable enhancements to this would include, provideing a method to mark
a path to not attempt this crude form of auto recovery and a way to mark
a failed path as good. Finally a device wide flag to disable
auto-recovery.
A disadvantage to this approach is that it would potentially, multiply
the amount or time it takes to ultimately fail the attempt, by the
number of paths. This would seem to be acceptable since the alternative
is to fail the operation when a good route might exist.
I would appreciate any thoughts, flames, or suggestions.
On 2002-01-17T15:36:54,
Brian Beattie <[email protected]> said:
> Probable enhancements to this would include, provideing a method to mark
> a path to not attempt this crude form of auto recovery and a way to mark
> a failed path as good. Finally a device wide flag to disable
> auto-recovery.
>
> A disadvantage to this approach is that it would potentially, multiply
> the amount or time it takes to ultimately fail the attempt, by the
> number of paths. This would seem to be acceptable since the alternative
> is to fail the operation when a good route might exist.
>
> I would appreciate any thoughts, flames, or suggestions.
Combined with the enhancements this makes a lot of sense.
The enhancements are very much required, especially the way to mark a path as
good again manually.
I would also liks easily parseable /proc file to query the status of a
multi-path device, including all paths associated with it.
Sincerely,
Lars Marowsky-Br?e <[email protected]>
--
Perfection is our goal, excellence will be tolerated. -- J. Yahl
On Thu, 2002-01-17 at 23:07, Lars Marowsky-Bree wrote:
> On 2002-01-17T15:36:54,
> Brian Beattie <[email protected]> said:
>
> > Probable enhancements to this would include, provideing a method to mark
> > a path to not attempt this crude form of auto recovery and a way to mark
> > a failed path as good. Finally a device wide flag to disable
> > auto-recovery.
...
>
> Combined with the enhancements this makes a lot of sense.
>
> The enhancements are very much required, especially the way to mark a path as
> good again manually.
>
> I would also liks easily parseable /proc file to query the status of a
> multi-path device, including all paths associated with it.
>
>
I have some stuff that uses sysctl, which shows in /proc/sys/... that I
was planning to use.