Re: Storage - redundant path failover / failback - quo vadis

[Jonathan Lundell]

At 9:03 AM +0200 2001-05-18, [e-mail] 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.