[dm-devel] RE: Is there a grand plan for FC failover?

["Smart, James" <James Smart Emulex com>]

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 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 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 vger kernel org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>