>>>>> "Laurence" == Laurence Oberman <lober...@redhat.com> writes:
Laurence,
The target is reporting inconsistent values here:
> [root@srptest queue]# sg_inq --p 0xb0 /dev/sdb
> VPD INQUIRY: Block limits page (SBC)
> Maximum compare and write length: 1 blocks
> Optimal transfer length granularity: 256 blocks
> Maximum transfer length: 256 blocks
> Optimal transfer length: 768 blocks
OPTIMAL TRANSFER LENGTH GRANULARITY roughly translates to physical block
size or RAID chunk size. It's the smallest I/O unit that does not
require read-modify-write. It would typically be either 1 or 8 blocks
for a drive and maybe 64, 128 or 256 for a RAID5 array. io_min in
queue_limits.
OPTIMAL TRANSFER LENGTH indicates the stripe width and is a multiple of
OPTIMAL TRANSFER LENGTH GRANULARITY. io_opt in queue_limits.
MAXIMUM TRANSFER LENGTH indicates the biggest READ/WRITE command the
device can handle in a single command. In this case 256 blocks so that's
128K. max_dev_sectors in queue_limits.
>From SBC:
"A MAXIMUM TRANSFER LENGTH field set to a non-zero value indicates the
maximum transfer length in logical blocks that the device server accepts
for a single command shown in table 250. If a device server receives one
of these commands with a transfer size greater than this value, then the
device server shall terminate the command with CHECK CONDITION status
[...]"
So those reported values are off.
logical block size <= physical block size <= OTLG <= OTL <= MTL
Or in terms of queue_limits:
lbs <= pbs <= io_min <= io_opt <=
min_not_zero(max_dev_sectors, max_hw_sectors, max_sectors)
--
Martin K. Petersen Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
