Re: [Qemu-devel] [PATCH 1/2] iscsi: Use bs->sg for everything else than disks

[Kevin Wolf <kwolf@redhat.com>]

Am 05.03.2014 um 17:02 hat Peter Lieven geschrieben:
> Am 05.03.2014 16:00, schrieb Kevin Wolf:
> > The current iscsi block driver code makes the rather arbitrary decision
> > that TYPE_MEDIUM_CHANGER and TYPE_TAPE devices have bs->sg = 1 and all
> > other device types are disks.
> >
> > Instead of this, check for TYPE_DISK to expose the disk interface and
> > make everything else bs->sg = 1. In particular, this includes devices
> > with TYPE_STORAGE_ARRAY, which is what LUN 0 of an iscsi target is.
> > (See https://bugzilla.redhat.com/show_bug.cgi?id=1067784 for the exact
> > scenario.)
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >  block/iscsi.c | 9 ++++-----
> >  1 file changed, 4 insertions(+), 5 deletions(-)
> >
> > diff --git a/block/iscsi.c b/block/iscsi.c
> > index 0a15f53..b490e98 100644
> > --- a/block/iscsi.c
> > +++ b/block/iscsi.c
> > @@ -1231,12 +1231,11 @@ static int iscsi_open(BlockDriverState *bs, QDict *options, int flags,
> >      bs->total_sectors = sector_lun2qemu(iscsilun->num_blocks, iscsilun);
> >      bs->request_alignment = iscsilun->block_size;
> >  
> > -    /* Medium changer or tape. We dont have any emulation for this so this must
> > -     * be sg ioctl compatible. We force it to be sg, otherwise qemu will try
> > -     * to read from the device to guess the image format.
> > +    /* We don't have any emulation for devices other than disks and CD-ROMs, so
> > +     * this must be sg ioctl compatible. We force it to be sg, otherwise qemu
> > +     * will try to read from the device to guess the image format.
> >       */
> > -    if (iscsilun->type == TYPE_MEDIUM_CHANGER ||
> > -        iscsilun->type == TYPE_TAPE) {
> > +    if (iscsilun->type != TYPE_DISK && iscsilun->type != TYPE_ROM) {
> >          bs->sg = 1;
> >      }
> >  
> We have ioctl support in the iscsi block driver only for Linux. Is this a problem?

Should be okay. It will cause the requests to fail, obviously
(bdrv_ioctl returns -ENOTSUP, and bdrv_aio_ioctl returns NULL), but
callers seem to cope with it and if we don't know how to handle the
request, that's the right thing to do.

Kevin