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@xxxxxxxxxx] > Sent: Wednesday, January 28, 2004 3:48 PM > To: Philip R. Auld > Cc: James Bottomley; Simon Kelley; SCSI Mailing List; > dm-devel@xxxxxxxxxxx > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html >