When trying to compile libiscsi on a 32 bit Ubuntu 10.04 with gcc 4.4.3
errors like the following are produced:
test_get_lba_status_beyond_eol.c:45: error: integer constant is too
large for ‘long’ type
This is because we don't specify that we are explictly compiling to the
c99 standard and as such gcc defaults to gnu90 standard. This in turn
means the maximum default type of integer literals is unsigned long int
which not big enough to hold the literal on a 32 bit architecture.
Fix this by adding the ULL suffix to all large integer literals.
Signed-off-by: Sitsofe Wheeler <sitsofe@yahoo.com>
As far as I know SPC-4 does not allow unaligned unmap requests to
fail. The only phrase I found in SPC-4 about unaligned unmap
requests is the following: "An unmap request with a starting LBA
that is not optimal may result in unmap operations on fewer LBAs
than requested." Hence check that unaligned unmap requests succeed.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
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>
Support for WRITE SAME with NUMBER OF LOGICAL BLOCKS = 0 is optional.
Hence set NUMBER OF LOGICAL BLOCKS to 0 if this value is supported
and set this parameter to 1 otherwise.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
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>
according to SBC-2 the alloc length should be at least 5 when
evpd is set to zero.
Also don't leak task if SPC-3 or later.
Signed-off-by: Peter Lieven <pl@kamp.de>
the test became nearly useless when reverting most
of its contents in commit 7d96336.
This patch adds some useful stuff back. While
we can't check that unmapped blocks are deallocated
we still can check that the blocks surrounding the
unmapped area don't get dealloaced.
Signed-off-by: Peter Lieven <pl@kamp.de>
Although SPC-2 specifies that a reservation conflict should be
reported when TEST UNIT READY is received from another initiator than
the registered initiator, it is an established practice that TEST
UNIT READY is accepted in this case. Hence use the MODE SENSE command
to test the effect of the RESERVE command instead of TEST UNIT READY.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
From the SBC-4 section about the block limits VPD page: "A write
same non-zero (WSNZ) bit set to one indicates that the device
server does not support a value of zero in the NUMBER OF LOGICAL
BLOCKS field in the WRITE SAME command CDBs (see 5.45, 5.46, and
5.47). A WSNZ bit set to zero indicates that the device server may
or may not support a value of zero in the NUMBER OF LOGICAL BLOCKS
field of the WRITE SAME commands." Hence verify that WRITE SAME
with NUMBER OF LOGICAL BLOCKS set to zero fails if WSNZ = 0.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
RFC 3720 is not clear about whether a target should return SUCCESS
or CHECK CONDITION if SPDTL > EDTL. Hence accept both. See also
Fred Knight, Re: [Ips] Data Out residual overflow/underflow handling,
IETF mailing list archive, 21 September 2012
(http://www.ietf.org/mail-archive/web/ips/current/msg02756.html).
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
We can not test that UNMAP will actually unmap anything even if
it returned status GOOD from the device.
Devices are allowed to "do nothing and return status GOOD" whenever they
want to.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Add a test for unmapping a single range of blocks and that
get_lba_status returns correct data.
Test unmapping a single block at offsets 0-255
Test unmapping 1-255 blocks at offset 0 and verify that
get_lba_status at LBA 0 returns a descriptor of 1-255 blocks.
get_lba_status at the last block of the unmapped range returns
a descriptor for a single block.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Dell Equallogic sans report an invalid LBA offset in the descriptor when
using 4k LUNs. Check the descriptor for consistency with the request.
Signed-off-by: Peter Lieven <pl@kamp.de>
- 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.
Rename the macros for managing the linked lists from SLIST_* to ISCSI_LIST_*
to avoid a clash on *BSD which already have other macros SLIST_*
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Allow specifying a --test <file> in which case the tests listed in the file
will be executed.
This makes it easier than having to specify a potentially huge number
of tests on the command line.
The first byte of CDB USAGE FIELD contains the opcode value itself, not
0xff.
From SPC4 :
...
The first byte of the CDB USAGE FIELD
field shall contain the operation code for the command being queried.
...
Recent SBC specs say (when the WSNZ bit is set to one and the NUMBER OF LOGICAL
BLOCKS field is set to zero) or (if MAXIMUM WRITE SAME LENGTH is greater than 0
and the number of logical blocks specified to be written exceeds the MAXIMUM
WRITE SAME LENGTH) the server should terminate with CHECK CONDITION, set the
sense key to ILLEGAL REQUEST and the additional sense code to INVALID FIELD IN
CDB.
Update the WRITESAME tests to cope with this.
