From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57336) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aGXUw-0001Gk-J1 for qemu-devel@nongnu.org; Tue, 05 Jan 2016 14:42:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aGXUv-0003Vg-Ng for qemu-devel@nongnu.org; Tue, 05 Jan 2016 14:42:26 -0500 References: <1451359934-9236-1-git-send-email-lszhu@suse.com> From: John Snow Message-ID: <568C1C9A.7090802@redhat.com> Date: Tue, 5 Jan 2016 14:42:18 -0500 MIME-Version: 1.0 In-Reply-To: <1451359934-9236-1-git-send-email-lszhu@suse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] send readcapacity10 when readcapacity16 failed List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhu Lingshan , qemu-block@nongnu.org Cc: pbonzini@redhat.com, pl@kamp.de, qemu-devel@nongnu.org, ronniesahlberg@gmail.com On 12/28/2015 10:32 PM, Zhu Lingshan wrote: > When play with Dell MD3000 target, for sure it > is a TYPE_DISK, but readcapacity16 would fail. > Then we find that readcapacity10 succeeded. It > looks like the target just support readcapacity10 > even through it is a TYPE_DISK or have some > TYPE_ROM characteristics. > > This patch can give a chance to send > readcapacity16 when readcapacity10 failed. > This patch is not harmful to original pathes > > Signed-off-by: Zhu Lingshan > --- > block/iscsi.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/block/iscsi.c b/block/iscsi.c > index bd1f1bf..c8d167f 100644 > --- a/block/iscsi.c > +++ b/block/iscsi.c > @@ -1243,8 +1243,9 @@ static void iscsi_readcapacity_sync(IscsiLun *iscsilun, Error **errp) > iscsilun->lbprz = !!rc16->lbprz; > iscsilun->use_16_for_rw = (rc16->returned_lba > 0xffffffff); > } > + break; > } > - break; > + //fall through to try readcapacity10 instead > case TYPE_ROM: > task = iscsi_readcapacity10_sync(iscsilun->iscsi, iscsilun->lun, 0, 0); > if (task != NULL && task->status == SCSI_STATUS_GOOD) { > For the uninitiated, why does readcapacity16 fail? My gut feeling is that this is a hack, because: - Either readcapacity16 should work, or - We shouldn't be choosing 10/16 based on the target type to begin with but I don't know much about iSCSI, so maybe You, Paolo or Peter could fill me in. --js