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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/