On 2002-09-09T11:40:26,
Mike Anderson <andmike@us.ibm.com> said:
> When you get into networking I believe we may get into path failover
> capability that is already implemented by the network stack. So the
> paths may not be visible to the block layer.
It depends. The block layer might need knowledge of the different paths for
load balancing.
> The utility does transcend SCSI, but transport / device specific
> characteristics may make "true" generic implementations difficult.
I disagree. What makes "generic" implementations difficult is the absolutely
mediocre error reporting and handling from the lower layers.
With multipathing, you want the lower level to hand you the error
_immediately_ if there is some way it could be related to a path failure and
no automatic retries should take place - so you can immediately mark the path
as faulty and go to another.
However, on a "access beyond end of device" or a clear read error, failing a
path is a rather stupid idea, but instead the error should go up immediately.
This will need to be sorted regardless of the layer it is implemented in.
How far has this been already addressed in 2.5 ?
> > > For sd, this means if you have n paths to each SCSI device, you are
> > > limited to whatever limit sd has divided by n, right now 128 / n.
> > > Having four paths to a device is very reasonable, limiting us to 32
> > > devices, but with the overhead of 128 devices.
> >
> > I really don't expect this to be true in 2.6.
> >
> While the device space may be increased in 2.6 you are still consuming
> extra resources, but we do this in other places also.
For user-space reprobing of failed paths, it may be vital to expose the
physical paths too. Then "reprobing" could be as simple as
dd if=/dev/physical/path of=/dev/null count=1 && enable_path_again
I dislike reprobing in kernel space, in particular using live requests as
the LVM1 patch by IBM does it.
Sincerely,
Lars Marowsky-Brée <lmb@suse.de>
-- Immortality is an adequate definition of high availability for me. --- Gregory F. Pfister- 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/
This archive was generated by hypermail 2b29 : Sun Sep 15 2002 - 22:00:21 EST