Re: question about scsi generic behavior

Re: question about scsi generic behavior

[David Chambliss]

I think you need to set bpt=8 .

It is possible to set some drives to block sizes other than 512 bytes, and
hardcoding 512 is not a good idea, especially in code that might last a
while.  In a few years we might have 4096-byte blocks to let the drives use
more powerful error correcting codes.

David Chambliss
Research Staff Member, Computer Science /Storage Systems
IBM Research Division
(408) 927-2243  (TL 457-2243)
FAX (408) 927-3497

Re: question about scsi generic behavior

[Douglas Gilbert]

hiren_mehta@agilent.com wrote:
> 
> Hi List,
> 
> I am trying to use sg_dd which goes through the scsi generic driver.
> This is how use it.
> 
> sg_dd if=/dev/zero of=/dev/sg5 bs=4096 count=1
> 
> And sg5 is actually a disk.

See "man sg_dd" which is provided with the sg_utils
package. The "bs" argument given to sg_dd must match
the physical block size of the device. [This is different from
"dd" in which bs can sensibly be an integral multiple of the 
physical block size.] The above command would have written 
zeroes over the first 512 byte block on the disk.  So the 
above should probably read:
  sg_dd if=/dev/zero of=/dev/sg5 bs=512 count=8
 
> The question that I have is, does the scsi generic driver have a knowledge
> about what kind of device it is dealing with ? 

No. It assumes as little as possible. It only does a
READ CAPACITY if a "count" argument is not given.
One reason is that not all devices that I may wish
to use sg_dd on support READ CAPACITY (or the figure
is wrong (e.g. cdroms)). In the case of the above 
command, only one WRITE(10) SCSI command should be 
issued to the disk.

> As you know, all disk drives
> have block size of 512 bytes. So, according to the above command, I am
> suppose
> write 4096 bytes of data. But when my driver gets the CDB, I see that
> the transfer length is set to 1 block instead of 8 blocks. 

As expected.

> And to transfer
> 4096 bytes, obviously we need transfer length=8 in CDB. Since, the transfer
> length
> is set to 1, the drive comes back with 1 512 byte block and then comes back
> with
> a good status because of which sg_dd command is not able to transfer all
> 4096 bytes
> of data.
> 
> Any input on this ?

To control the number of blocks transferred with each SCSI
command, the sg_dd command has a "bpt" (blocks per transfer)
command. Its default value is 128. The command:
  sg_dd if=/dev/zero of=/dev/sg5 bs=512 count=8 bpt=5
will transmit two SCSI commands, the first writing 5
512 byte blocks from block number 0, while the second
SCSI command will write 3 blocks from block number 5.
[/dev/sg5 is again assumed to be a disk blocked to 512 bytes.]
This is a finer grain of control than offered by the
generic dd command.

Doug Gilbert

RE: question about scsi generic behavior

[David Chambliss]

Hiren,
I think you are misunderstanding the parms of sg_dd (as I was, in my first
response).  <count> is the number of blocks, right?  It is transferring one
block, as you requested.  You lied to it and told it the block size was
2048.  It is a quite sensible choice for it to ignore this when a block
device is used, and use the actual block size (and therefore set FCP_DL =
512).  Alternatively, it could trust you, prepare a 2048-byte buffer, fill
it from /dev/zero, and set FCP_DL=2048.  Either way the behavior required
of the disk is to write one block.

If you want to write 2048 bytes (4 blocks) then may I recommend:
sg_dd if=/dev/zero of=/dev/sg5 count=4,

BTW, there is a clear difference in meaning between FCP_DL and any
length-determining fields in the CDB (such as the block count in READ or
WRITE).  FCP_DL specifies an upper limit to the amount of data transferred.
If FCP_DL exceeds the data length implied by processing of the command, it
is not an error.  The device server is *required* to complete the command
per the CDB, performing the necessary data transfers.  When FCP_RSP is
sent, the RESID field and the underrun bit are set appropriately.  The SCSI
status is unchanged by the existence of an underrun.  For some important
commands (like INQUIRY) an underrun is a typical outcome.

The meaning of the SCSI CDB is *never* modified to match the FCP_DL value.
The closest we get is in an overrun case.  When target processing tries to
make a transfer that goes past FCP_DL, the FCP_RSP is sent and the SCSI
task is terminated.  Usually no data is transferred or written to media,
though this is not a requirement of the standard.

David

Hiren Mehta wrote:

Well, the problem is not with non-512byte block device. The problem is
if the device is 512 byte block-sized device and if you use sg_dd with
bs=1024 or bs=2048, then it fails. I can understand if this fails
on a sequential device. But this fails on a disk. To be specific,
the problem is this : in case of fibre channel, you can specify
the FCP_DL in addition to the transfer-length which goes into CDB.
Now, when e.g. we use the following command,

sg_dd if=/dev/zero of=/dev/sg5 bs=2048 count=1,

and if in the low-level driver, we set the FCP_DL to 2048 and
in the CDB portition of FCP_CMND if we set the transfer-length to 1,
then the drive may not honour the FCP_DL and just look at the
transfer-length
and send XFER_RDY for 512 byte data. Once the HBA transfers the 512 byte of
data, then drive will send FCP_STATUS with status=good. Well, if you
look at it, we want to transfer 2048 bytes of data to the device,
whereas the device completes the command with good status after
transferring only 512 bytes. I hope this is more clear.

I guess, probably the sg driver is  probably not looking at the block
size information returned in response to READ_CAPACITY command.

Regards,
-hiren
(408)970-3062
hiren_mehta@agilent.com

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Friday, June 08, 2001 5:37 PM
> To: hiren_mehta@agilent.com
> Cc: chamb@almaden.ibm.com; linux-scsi@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: question about scsi generic behavior
>
>
> > Hardcoding  of block size to 512 bytes for disk devices is
> what currently
> > either the block device driver or the sd driver is doing.
> Because, if
>
> I'm using 2048 byte block sized scsi media just fine. I've
> not tried using
> sg on the same device
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org

RE: question about scsi generic behavior

[hiren_mehta]

Well, the problem is not with non-512byte block device. The problem is
if the device is 512 byte block-sized device and if you use sg_dd with
bs=1024 or bs=2048, then it fails. I can understand if this fails
on a sequential device. But this fails on a disk. To be specific,
the problem is this : in case of fibre channel, you can specify
the FCP_DL in addition to the transfer-length which goes into CDB.
Now, when e.g. we use the following command,

sg_dd if=/dev/zero of=/dev/sg5 bs=2048 count=1,

and if in the low-level driver, we set the FCP_DL to 2048 and
in the CDB portition of FCP_CMND if we set the transfer-length to 1,
then the drive may not honour the FCP_DL and just look at the
transfer-length
and send XFER_RDY for 512 byte data. Once the HBA transfers the 512 byte of
data, then drive will send FCP_STATUS with status=good. Well, if you
look at it, we want to transfer 2048 bytes of data to the device, 
whereas the device completes the command with good status after 
transferring only 512 bytes. I hope this is more clear.

I guess, probably the sg driver is  probably not looking at the block 
size information returned in response to READ_CAPACITY command.

Regards,
-hiren
(408)970-3062
hiren_mehta@agilent.com

> -----Original Message-----
> From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk]
> Sent: Friday, June 08, 2001 5:37 PM
> To: hiren_mehta@agilent.com
> Cc: chamb@almaden.ibm.com; linux-scsi@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: question about scsi generic behavior
> 
> 
> > Hardcoding  of block size to 512 bytes for disk devices is 
> what currently 
> > either the block device driver or the sd driver is doing. 
> Because, if
> 
> I'm using 2048 byte block sized scsi media just fine. I've 
> not tried using
> sg on the same device
> 

Re: question about scsi generic behavior

[Alan Cox]

> Hardcoding  of block size to 512 bytes for disk devices is what currently 
> either the block device driver or the sd driver is doing. Because, if

I'm using 2048 byte block sized scsi media just fine. I've not tried using
sg on the same device

RE: question about scsi generic behavior

[hiren_mehta]

Well, 

Hardcoding  of block size to 512 bytes for disk devices is what currently 
either the block device driver or the sd driver is doing. Because, if
I run dd to the same device using the corresponding block device (sde)
it runs fine. So, I feel that either the sg driver or the block device
driver
or sd driver needs to be fixed. 
One more thing is that, sg driver can find out from READ_CAPACITY the
current
block size on the device. So, if dd specifies bs=4096 and count=1, then
accordingly, the sg driver should set the count to 8 and bs to the bs of
the device. IMHO, untimately, the total transfer length is what matters.

Regards,
-hiren
(408)970-3062
hiren_mehta@agilent.com

> -----Original Message-----
> From: David Chambliss [mailto:chamb@almaden.ibm.com]
> Sent: Friday, June 08, 2001 4:49 PM
> To: hiren_mehta@agilent.com
> Cc: linux-scsi@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: question about scsi generic behavior
> 
> 
> 
> I think you need to set bpt=8 .
> 
> It is possible to set some drives to block sizes other than 
> 512 bytes, and
> hardcoding 512 is not a good idea, especially in code that 
> might last a
> while.  In a few years we might have 4096-byte blocks to let 
> the drives use
> more powerful error correcting codes.
> 
> David Chambliss
> Research Staff Member, Computer Science /Storage Systems
> IBM Research Division
> (408) 927-2243  (TL 457-2243)
> FAX (408) 927-3497
> 

question about scsi generic behavior

[hiren_mehta]

Hi List,

I am trying to use sg_dd which goes through the scsi generic driver.
This is how use it.

sg_dd if=/dev/zero of=/dev/sg5 bs=4096 count=1

And sg5 is actually a disk. 

The question that I have is, does the scsi generic driver have a knowledge
about what kind of device it is dealing with ? As you know, all disk drives
have block size of 512 bytes. So, according to the above command, I am
suppose
write 4096 bytes of data. But when my driver gets the CDB, I see that
the transfer length is set to 1 block instead of 8 blocks. And to transfer
4096 bytes, obviously we need transfer length=8 in CDB. Since, the transfer
length
is set to 1, the drive comes back with 1 512 byte block and then comes back
with 
a good status because of which sg_dd command is not able to transfer all
4096 bytes
of data.

Any input on this ?

Regards,
-hiren
hiren_mehta@agilent.com