Bug 10554 - scsi_scan doesn't set the queue depth for tape drive
Summary: scsi_scan doesn't set the queue depth for tape drive
Status: RESOLVED INSUFFICIENT_DATA
Alias: None
Product: SCSI Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: scsi_drivers-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-04-25 08:28 UTC by François Lerat
Modified: 2015-02-19 15:12 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.16
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description François Lerat 2008-04-25 08:28:55 UTC
Latest working kernel version: 2.6.16
Distribution: Suse
Hardware Environment: IA64
Software Environment: Suse + Backup Software
Problem Description:
scsi_scan doesn't set the queue depth for tape drive.
I'm using an STK 9840B (scsi fiber tape drive) and when I try to acces with 2 driver on the same device, device report an error.



I'm using a software that monitor the tape drive quality. This software use the "sg" driver to acces to tape drive. The backup software use "st" to read/ write data.

When the backup software and my software acces in the same time the data transfert failed.
I'm using a STK 9840B tape drive and when I test with IBM LTO1 it's work.

The main difference between the both drive is that STK doesn't support queue command (qdepth=1 or 0) and IBM support queue qdepth > 1.

I'm using a qlogic fiber channel, when I'm force the ql2xmaxqdpeth to 1, all is working very well. But this paramater is for all devices connected to Qlogic Fiber channel. In my configuartion have 1TB a disk and performence is low due to qdpeth=1.

On the scsi_scan.c, we have the method scsi_add_lun who read the CmdQue from the inquiry and set the tagged flag:

if ((sdev->scsi_level >= SCSI_2) && (inq_result[7] & 2) &&
          !(*bflags & BLIST_NOTQ))
            sdev->tagged_supported = 1; 

---> CmdQue = inq_result[7] & 2 

STK: CmdQue = 0
IBM: CmdQue = 1

But according to www.t10.org and SPC-2:

"A command queuing (CMDQUE) bit of one indicates that the device supports tagged tasks (command queuing) for this logical unit (see SAM-2). A value of zero indicates the device server may support tagged tasks for this logical
unit (see the BQUE bit, above)."

Note the "may support tagged" and in fact if you look the BQUE bit:
STK:  BQUE=0
IBM:  BQUE=0

For www.t10.org:
BQUE=0, CmdQue=0 : No command queuing of any kind supported.
BQUE=0, CmdQue=1 : Command queuing with all types of task tags supported.

scsi_scan do this:
STK:  sdev->tagged_supported = 0 and qdepth = ql2xmaxqdepth
IBM:  sdev->tagged_supported = 1 and qdepth = ql2xmaxqdepth

For me, scsi_scan must read the BQUE bit and set the qdepth to 1 for STK and to max for IBM.

Regards
Comment 1 xerofoify 2014-06-24 16:52:04 UTC
Can you test this against a Newer Kernel as this bug may be fixed as it's very old
since it's now 2014.
Thanks Nick

Note You need to log in before you can comment on or make changes to this bug.