Messages in this thread |  | | Date | Fri, 18 May 2001 08:32:36 -0700 | From | Jonathan Lundell <> | Subject | Re: Storage - redundant path failover / failback - quo vadis linux? |
| |
At 9:03 AM +0200 2001-05-18, Stefan.Bader@de.ibm.com 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |