From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755238Ab2BMHGJ (ORCPT ); Mon, 13 Feb 2012 02:06:09 -0500 Received: from e06smtp16.uk.ibm.com ([195.75.94.112]:59930 "EHLO e06smtp16.uk.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754978Ab2BMHGG (ORCPT ); Mon, 13 Feb 2012 02:06:06 -0500 Message-ID: <4F38B657.7060405@de.ibm.com> Date: Mon, 13 Feb 2012 08:05:59 +0100 From: Christian Borntraeger User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Lightning/1.0b2 Thunderbird/3.1.16 MIME-Version: 1.0 To: James Bottomley CC: Paolo Bonzini , Christian Hoff , borntrae@linux.vnet.ibm.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org, mst@redhat.com, rusty@rustcorp.com.au Subject: Re: Pe: [PATCH v5 1/3] virtio-scsi: first version References: <4F30F4EE.4080607@redhat.com> <4F311154.9080407@de.ibm.com> <4F3119A0.7080005@redhat.com> <4F312492.1040002@de.ibm.com> <4F313526.2050907@redhat.com> <4F3390FB.80107@redhat.com> <1329077777.21613.60.camel@dabdike.int.hansenpartnership.com> In-Reply-To: <1329077777.21613.60.camel@dabdike.int.hansenpartnership.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit x-cbid: 12021307-3548-0000-0000-00000105E941 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/02/12 21:16, James Bottomley wrote: > Well, no-one's yet answered the question I had about why. Just to give one example from a different angle: In the big datacenters tape libraries are still very important, and lots of them have a scsi attachement. virtio-blk certainly is not the right way to handle those. Furthermore it seems even pretty hard to craft a virtio-tape since most of those libraries have vendor specific library controls (via sg). We would need to duplicate scsi generic (hint, hint :-) > virtio-scsi seems to be a basic duplication of virtio-blk except that it seems to > fix some problems virtio-blk has. Namely queue parameter discover, > which virtio-blk doesn't seem to do. There may also be a reason to cut > the stack lower down. Error handling is most often cited for this, but > no-one's satisfactorily explaned why it's better to do error handling in > the guest instead of the host. > > Could someone please explain to me why you can't simply fix virtio-blk? I dont think that virtio-scsi will replace virtio-blk everywhere. For non-scsi block devices, image files or logical volumes virtio-blk seems to be the right approach, I think. > Or would virtio-blk maintainers give a reason why they're unwilling to > have it fixed? I dont consider virtio-blk broken. It just doesnt cover everything. Christian