From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:54105)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RIMa0-0008MM-44
	for qemu-devel@nongnu.org; Mon, 24 Oct 2011 11:36:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RIMZv-0004kv-Vg
	for qemu-devel@nongnu.org; Mon, 24 Oct 2011 11:36:48 -0400
Received: from mx1.redhat.com ([209.132.183.28]:22059)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1RIMZv-0004kY-Jh
	for qemu-devel@nongnu.org; Mon, 24 Oct 2011 11:36:43 -0400
Received: from int-mx12.intmail.prod.int.phx2.redhat.com
	(int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25])
	by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p9OFabFd003894
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
	for <qemu-devel@nongnu.org>; Mon, 24 Oct 2011 11:36:37 -0400
Message-ID: <4EA58604.6010401@redhat.com>
Date: Mon, 24 Oct 2011 17:36:36 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <1318503845-11473-1-git-send-email-pbonzini@redhat.com>
	<1318503845-11473-30-git-send-email-pbonzini@redhat.com>
	<4EA57FD6.4070703@redhat.com>
In-Reply-To: <4EA57FD6.4070703@redhat.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 29/35] scsi-disk: remove cluster_size
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org

On 10/24/2011 05:10 PM, Kevin Wolf wrote:
>> >  -    bdrv_get_geometry(s->qdev.conf.bs,&nb_sectors);
>> >  -    nb_sectors /= s->cluster_size;
>> >  -    if (nb_sectors) {
>> >  -        nb_sectors--;
>> >  +    if (s->qdev.blocksize) {
> When would it be 0? And wouldn't we crash with a zero blocksize anyway?

blocksize can be zero when passing through a removable medium and no 
medium has ever been inserted in the disk since the guest was started. 
In practice it won't crash because the guest will always send READ 
CAPACITY first, will see a unit attention condition, and will not 
attempt a read.

A more complete solution involves asking raw-posix for the logical block 
size (right now logical_block_size acts as both the emulated and host 
block size).  This would also be useful to make cache=none work with 
4k-sector disks without manually specifying logical_block_size. 
However, it's not 1.0 material.

Paolo