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>
The test:
"Test WRITESAME16 of 1-256 blocks at the end of the LUN by setting
number-of-blocks==0"
was passing 0 for the data length instead of the block count.
Signed-off-by: Chris Zankel <chris@zankel.net>
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>
Avoid that Valgrind reports complaints similar to the following:
Syscall param writev(vector[...]) points to uninitialised byte(s)
at 0x5567087: writev (writev.c:49)
by 0x5265AE0: iscsi_iovector_readv_writev (socket.c:492)
by 0x52666B5: iscsi_write_to_socket (socket.c:710)
by 0x5266CCC: iscsi_service (socket.c:852)
by 0x526751F: event_loop (sync.c:67)
by 0x5269B41: iscsi_scsi_command_sync (sync.c:1153)
by 0x4050F6: send_scsi_command (iscsi-support.c:245)
by 0x408007: compareandwrite (iscsi-support.c:1512)
by 0x40B6AD: test_compareandwrite_dpofua (test_compareandwrite_dpofua.c:69)
by 0x503EC99: ??? (in /usr/lib/libcunit.so.1.0.1)
by 0x503EF27: ??? (in /usr/lib/libcunit.so.1.0.1)
by 0x503F2A5: CU_run_all_tests (in /usr/lib/libcunit.so.1.0.1)
Address 0xffeffff10 is on thread 1's stack
in frame #8, created by test_compareandwrite_dpofua (test_compareandwrite_dpofua.c:30)
Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
- 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.
