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-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:26 EST