RE: allow_dio/SG_FLAG_DIRECT_IO for sr devices

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Douglas Gilbert wrote:
> Adar Dembo wrote:
> > When sending SG_IO ioctls to a device:
> > - /dev/sgX devices (using sg.c) follow the behavior described at
> > http://tldp.org/HOWTO/SCSI-Generic-HOWTO/dio.html in terms of
> > defaulting to indirect I/O, and using direct I/O only if both
> > /proc/scsi/sg/allow_dio and SG_FLAG_DIRECT_IO in the request are set.
> > - /dev/srX devices (using sr.c) default to direct I/O. At least, that
> > appears to be the case from inspecting the code, as
> > sr_block_ioctl->cdrom_ioctl->scsi_cmd_ioctl->sg_io->blk_rq_map_user-
> > >__blk_rq_map_user will attempt to map the pages, regardless of what
> > the user specified in the request or in the proc node.
> > 
> > This difference caught me by surprise; my expectation would be that an
> > sg_io_hdr_t passed via SG_IO would be serviced in the same way
> > regardless of the underlying driver. Is this a bug, or a feature? If
> > the latter, is it documented somewhere?
> 
> As the name suggests the SG_IO ioctl was originally
> implemented in the sg driver. Due to difficulties in
> discovering which sg device corresponded to a particular
> SCSI device node belonging to another driver (e.g. /dev/sr0
> belonging to the sr driver), the SG_IO ioctl was
> grafted on to various other drivers (in some cases via
> the block layer).
> 
> The result is not always pretty and there are many
> subtle differences. There is no 100% clean SCSI
> pass-through in Linux (and if there was it could not
> easily share a device with another high level SCSI driver
> such as sr). The sg and the bsg drivers give the cleanest
> pass-throughs. The rest tend to make assumptions appropriate
> to their class of devices. And it is not just the SG_IO
> ioctl that you need to take care of: some other drivers
> will hang on open() if the device is not ready and the
> O_NONBLOCK flag is not given.
> 
> Summary: the driver "owning" the file descriptor that
> the SG_IO ioctl uses, is in control.

Thanks for the response.

What you've described seems like a reasonable justification for why the different drivers should be allowed to handle SG_IO differently. That said, do you think it makes sense for the block layer's implementation to be extended to check allow_dio and/or SG_FLAG_DIRECT_IO, as the sg driver does?

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]
  Powered by Linux