[dm-devel] RE: Is there a grand plan for FC failover?
Smart, James
James.Smart at Emulex.com
Fri Jan 30 15:09:02 UTC 2004
I'd add one additional issue :
3) SCSI Reservations
I guess this could be considered a part of (2), but given that reservations
bring in a host of additional problems, and potentially brings up multi-host
configs/clusters as well...
-- James S
> -----Original Message-----
> From: Patrick Mansfield [mailto:patmans at us.ibm.com]
> Sent: Wednesday, January 28, 2004 3:48 PM
> To: Philip R. Auld
> Cc: James Bottomley; Simon Kelley; SCSI Mailing List;
> dm-devel at sistina.com
> Subject: Re: Is there a grand plan for FC failover?
>
>
> [cc-ing dm-devel]
>
> My two main issues with dm multipath versus scsi core multipath are:
>
> 1) It does not handle character devices.
>
> 2) It does not have the information available about the state of the
> scsi_device or scsi_host (for path selection), or about the elevator.
>
> If we end up passing all the scsi information up to dm, and
> it does the
> same things that we already do in scsi (or in block), what is
> the point of
> putting the code into a separate layer?
>
> More scsi fastfail like code is still needed - probably for
> all the cases
> where scsi_dev_queue_ready and scsi_host_queue_ready return 0
> - and more.
> For example, should we somehow make sdev->queue_depth available to dm?
>
> There are still issues with with a per path elevator (i.e. we have an
> elevator for each path rather than the entire device) that
> probably won't
> be fixed cleanly in 2.6. AFAIUI this requires moving dm from
> a bio based
> approach to a request based one.
>
> -- Patrick Mansfield
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-scsi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
More information about the dm-devel
mailing list