Re: [RFC] Multi-path IO in 2.5/2.6 ?

Lars Marowsky-Bree
2002-09-11T19:52:32Z

On 2002-09-11T14:37:40,
James Bottomley <James.Bottomley@steeleye.com> said:

> I think I see driverfs as the solution here. Topology is deduced by
> examining certain device and HBA parameters. As long as these parameters
> can be exposed as nodes in the device directory for driverfs, a user level
> daemon map the topology and connect the paths at the top. It should even be
> possible to weight the constructed multi-paths.

Perfect, I agree, should've thought of it. As long as this is simple enough
that it can be done in initrd (if / is on a multipath device...).

The required weighting has already been implemented in the LVM1 patch by IBM.
While it appeared overkill to me for "simple" cases, I think it is suited to
expressing proximity.

> This solution appeals because the kernel doesn't have to dictate policy,

Right.

> I've been think about this separately. FC in particular needs some type of
> event notification API (something like "I've just seen this disk" or "my
> loop just went down"). I'd like to leverage a mid-layer api into hot plug
> for some of this, but I don't have the details worked out.

This isn't just FC, but also dasd on S/390. Potentially also network block
devices, which can notice a link down.

> The probing issue is an interesting one. At least SCSI has the ability to
> probe with no IO (something like a TEST UNIT READY) and I assume other block
> devices have something similar. Would it make sense to tie this to a single
> well known ioctl so that you can probe any device that supports it without
> having to send real I/O?

Not sufficient. The test is policy, so the above applies here too ;-)

In the case of talking to a dual headed RAID box for example, TEST UNIT READY
might return OK, but the controller might refuse actual IO, or the path may be
somehow damaged in a way which is only detected by doing some "large" IO. Now,
this might be total overkill for other scenarios.

I vote for exposing the path via driverfs (which, I think, is already
concensus so the multipath group, topology etc can be used) and allowing
user-space to reenable them after doing whatever probing deemed necessary.

What are your ideas on the potential timeframe?

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-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html