Re: Is there a grand plan for FC failover?

James Bottomley
2004-01-28T16:57:39Z

On Wed, 2004-01-28 at 09:02, Philip R. Auld wrote:
> 1) load balancing when possible: it's not enough to be just a
> failover mechanism.

For first out, a failover target supplies most of the needs. Nothing
prevents an aggregation target being added later, but failover is
essential.

> 2) requiring a userspace program to execute for failover is
> problematic when it could be the root disk that needs
> failing over.

Userspace is required for *configuration* not failover. The path
targets failover automatically as they see I/O down particular paths
timing out or failing. That being said, nothing prevents async
notifications via hotplug also triggering a failover (rather than having
to wait for timeout etc) but it's not required.

> 3) Handling partitions is a problem.

It is? How? The block approach can sit either above or below partitions
(assuming a slightly more flexible handling of partitions that dm
provides).

> I see multipath and md/RAID as two different animals. Multipathing is
> multiple ways to reach the same physical block. That is it's under
> the logical layer. While RAID is multiple ways to reach the same
> logical block. It's basically many-to-one vs one-to-many. Having
> multiple physical paths to a logical partition is a little
> counter-intuitive.

Nothing in the discussion assumed them to be similar. The notes were
that md already had a multi-path target, and that translated error
indications would be useful to software raid. Thus designing the
fastfail to cater to both looks like a good idea, but that's just good
design. Robust multi-pathing and raid will be built on top of
scsi/block fastfail.

James