At 9:03 AM +0200 2001-05-18, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
