Change all tests in the old testsuite to check 0block tests 2 blocks past the end of the device, just like the new testsuite.
These tests check that we get an error if we do a 0-block read/write etc beyond the end of the device.
In the SBC standard, the only thing that discusses LBA_OUT_OF_RANGE is wordings
such as this :
If the LBA plus the transfer length exceeds the capacity of the medium,
then the device server shall terminate the command with CHECK CONDITION
status with the sense key set to ILLEGAL REQUEST and the additional
sense code set to LOGICAL BLOCK ADDRESS OUT OF RANGE.
This is very clear for when transfer length is > 0, but what when
transfer length is == 0?
Assume we have a device that is 0x31fff in size.
With this wording, if we read 1 block at LBA : 0x31fff we end up at 0x32000
and this is at the end, but not beyond the end.
We are reading/accessing the last block at 0x31fff and we stop at 0x32000.
Similarly, if we are reading 1 block, starting at 0x32000 and reading to 0x32001 which would be LBA_OUT_OF_RANGE since we are accessing beyond the end of the device.
The question now is what happens if we try to read 0-blocks just at the edge at the end of the device.
I.e. What is we try to read 0 blocks at LBA:0x32000 ?
Looking at the standard, the wordings say that this should be fine.
Because the SBC standard only says that we should check LBA+transfer length.
Thus since 0x31fff + 1 block is exactly the same as 0x32000 + 0 blocks
thus a device SHOULD allow reading of 0 blocks just at the end.
This is the conclusion from reading SBC by the letter. However It might be unreasonable to do so and it might be wiser to just stay away from this ambigous area of SBC.
Following the SBC standard by the letter, the new test suite was wrong since it should have flagged this as a failure. But it did checks on one block beyond the blobk at the end of the device. It checked that we would fail for 0x32001 in the example above.
Strictly, I should have fixed the new test to check 0x32000 but I think it might be unreasonably to enforce something here for this ambigous area of "what happens when accessing 0 blocks just at the edge of the device".
So instead I have changed the OLD tests so that they now check one block further on. In the example above it means they too now check 0x32001 instead of 0x32000.
Technically speaking this is wrong, but this is the imho reasonable thing to do.
This directory contains a libiscsi based test tool.
The purpose of this test tool is to validate iscsi and scsi protocol compliance of a target.
Initiatornames and LUN-masking
==============================
If the target uses lun-masking or ACLs you need to set the target up to allow
iscsi-test access to the LUNs you want to test.
By default iscsi-test uses the following two initiator names :
iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-test
iqn.2007-10.com.github:sahlberg:libiscsi:iscsi-test-2
Most tests only use the first name but some tests, such as the RESERVE/RELEASE
tests, will use both names.
Optionally you can use different initiatir names for your testing using the
command line flags :
--initiator-name=iqn.<some other name>
--initiator-name-2=iqn.<another different name>
Listing all tests and test details:
===================================
The --list argument is used to show a lost of all major tests that are available
iscsi-test --list
To list all tests and a description of each test and subtests, use
iscsi-test --list --info
Running tests:
==============
Running tests you need to specify which test to run using the --test argument.
This can either be the name of one specific test or a set of tests using * as
the wildcard character.
Example to run one specific test :
iscsi-test --test="T1020_bufferoffset_invalid" iscsi://127.0.0.1/iqn.ronnie.test/1
Example to run all READ10 tests :
iscsi-test --test="*read10*" iscsi://127.0.0.1/iqn.ronnie.test/1
Or to run every test :
iscsi-test --test="*" iscsi://127.0.0.1/iqn.ronnie.test/1
6a3888e39e