Only perform the test with 65536 blocks on block devices with at
least that number of blocks. Fix the 65536 block test log message.
Generalize the WRITE SAME(10) 256-block test log messages. Fix
interpretation of the MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT field.
A quote from SPC-4: "If there is no limit on the number of UNMAP
block descriptors contained in the parameter data, then the device
server shall set the MAXIMUM UNMAP BLOCK DESCRIPTOR COUNT field to
FFFF_FFFFh."
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
- writesame10_unmap_until_end, writesame16_unmap, writesame16_unmap_until_end were doing an CU_ASSERT *PER-BYTE* in the verification phase,
which was very CPU-intensive. This change uses memcmp on a whole block which finishes much quicker.
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=256
then verify that both WRITESAME10 and WRITESAME16 can unmap with a
number of blocks == 2 byte field.
If not, then verify that a 256 block unmap results in INVALID FIELD IN CDB
If BLockLimits->MaxWriteSameLength is 0 (no limit) or >=65536
then verify that WRITESAME16 can unmap with a
number of blocks == 3 byte field.
If not, then verify that a 65536 block unmap results in INVALID FIELD IN CDB
From discussions on linux-scsi there are devices that support WRITESAME16
but where the implementation only looks at the low 2 bytes of the 4 bytes for
num-blocks in the CDB.
This added test aims to find and flag such devices.
