From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Smart Subject: Re: [Patch 0/7] pvSCSI driver Date: Fri, 14 Mar 2008 15:04:06 -0400 Message-ID: <47DACC26.2030105@emulex.com> References: <20080304130557.GA29030@weybridge.uk.xensource.com> <20080307112058.C6D4.EB2C8575@jp.fujitsu.com> Reply-To: James.Smart@Emulex.Com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: James Harper Cc: Jun Kamada , Steven Smith , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org James Harper wrote: > This reset stuff seems like a lot of extra work for probably not much > benefit though. This ends up being the crux of it... It all depends on how important the use of scsi is to the consumer. In otherwords, a scsi disk, layered under LVM, filesystems, etc, the nuances of the resets and inter-relations between luns and targets isn't that meaningful and they will happily live in a world with these things are emulated. However, if the scsi disk is talked to directly via things like sg tools, or things like multipathing software (where failover is disk & target specific), it matters more. And if the scsi disk is handed all the way to the database, it matter *much* *much* more. In fact, this is one reason you find very enterprise databases supported in virtualized environments. All this hints at levels of pass-thru. Granted, you can always take one step at a time. -- james