[lkml]   [2001]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Storage - redundant path failover / failback - quo vadis linux?
At 9:03 AM +0200 2001-05-18, wrote:
> >My question is which way is the more probable solution for future linux
> >kernels?
> >The low-level-approach of the "T3"-patch requires changes to the
> >scsi-drivers and the hardware-drivers but provides optimal communication
> >between the driver and the hardware
>Thinking about it: if there would be some sort of 'available' flag
>in the gendisk structure, that would be updated by the low-level
>drivers. This could the used by a high-level design to use or skip a
>failed device/path... In the S/390 (or zSeries) environment the
>device drivers are even able to detect a failing connection even if
>there is no data going to a device. That way the device would be
>disabled even _before_ anybody tries to write...
> >The high-level-approach of the "multipath"-personality is
> >hardware-independant but works very slowly. On the other hand I see no
> >clear way how to check for availability of the (previously failed) primary
> >channel to automate a fail-back.
>Well, slower, but I think there will be many that take that
>performance loss already by using lvm or md (for the benefit of
>flexible/large filesystems) this approach would add failover while
>beeing IMHO only a little less performant.

The flag idea, or some equivalent way for the low-level driver to
communicate to the multi-pathing level, seems exactly right. I'm
guessing that provision needs to be made for some
external-device-dependent means of signalling both failure and
recovery. There are potentially side-channel/out-of-band means to
communicate this kind of status from specific devices.
/Jonathan Lundell.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:53    [W:0.055 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site