Re: FC & MULTIPATH !? (any hope?)

Re: FC & MULTIPATH !? (any hope?)

[James Bottomley]

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

Re: FC & MULTIPATH !? (any hope?)

[Arjan van de Ven]

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

Re: FC & MULTIPATH !? (any hope?)

[Brian Beattie]

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.

Re: FC & MULTIPATH !? (any hope?)

[Lars Marowsky-Bree]

On 2002-01-14T11:53:07,
   Brian Beattie <alchemy@us.ibm.com> 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 <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

FC & MULTIPATH !? (any hope?)

[Mario Mikocevic]

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

Re: FC & MULTIPATH !? (any hope?)

[Lars Marowsky-Bree]

[-- Attachment #1: Type: text/plain, Size: 386 bytes --]

On 2002-01-14T12:33:01,
   Mario Mikocevic <mozgy@hinet.hr> 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 <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: FC & MULTIPATH !? (any hope?)

[Peter Rival]

Lars Marowsky-Bree wrote:

 > On 2002-01-14T12:33:01, Mario Mikocevic <mozgy@hinet.hr> 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

Re: FC & MULTIPATH !? (any hope?)

[Brian Beattie]

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.

Re: FC & MULTIPATH !? (any hope?)

[Lars Marowsky-Bree]

On 2002-01-17T15:36:54,
   Brian Beattie <alchemy@us.ibm.com> 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 <lmb@suse.de>

-- 
Perfection is our goal, excellence will be tolerated. -- J. Yahl

Re: FC & MULTIPATH !? (any hope?)

[Brian Beattie]

On Thu, 2002-01-17 at 23:07, Lars Marowsky-Bree wrote:
> On 2002-01-17T15:36:54,
>    Brian Beattie <alchemy@us.ibm.com> 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.