As reported by Sitsofe Wheeler, the WRITE SAME commands with zero blocks are
only issued if WSNZ == 0. WSNZ == 0 means that zero in the NUMBER OF LOGICAL
BLOCKS field means that all logical blocks until the end are affected. In
other words, the original code was fine. Hence revert commit dfff7e9d16.
Reported-by: Sitsofe Wheeler <sitsofe@yahoo.com>
2e947cc1de added logic to check that
targets missing zero block writesame support return INVALID_FIELD_IN_CDB
to such requests. However, this change incorrectly set the writesame
number_of_logical_blocks field to one.
Signed-off-by: David Disseldorp <ddiss@suse.de>
Skip 0-block WRITE SAME tests for targets that don't support these
operations, ie. they have write_same_no_zero (WSNZ) set in the
block limits vpd.
Also, fix the test:
"Test WRITESAME10 of 1-256 blocks at the end of the LUN by setting
number-of-blocks==0"
to actually pass 0 blocks instead of the number of remaining blocks to the end.
Signed-off-by: Chris Zankel <chris@zankel.net>
From the SPC-4 paragraph about WRITE SAME(10): "The WRITE SAME (10)
command requests that the device server transfer a single logical
block from the Data-Out Buffer [ ... ]". Hence always pass a data
buffer when sending a WRITE SAME(10) command.
Set the NDOB bit in the WRITE SAME(16) command if no data out buffer
is present.
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.
