Also test that IF the iSCSI layer provides 2 blocks of DATA-OUT but
the SCSI WRITE* command only covers one single block,
then only the first block will be modified but not the second block.
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.
in case the maximum number of reconnects is limited with
iscsi_set_reconnect_max_retries() the an iscsi_context
is leaked if the limit is exhausted.
Signed-off-by: Peter Lieven <pl@kamp.de>
If the amount of reconnects is limited with iscsi_set_reconnect_max_retries()
it might happen that iscsi_reconnect is called while there is already a deferred
reconnect.
Signed-off-by: Peter Lieven <pl@kamp.de>
The main part of this release is the introduction of a new
CUnit based test tool for iscsi and scsi : iscsi-test-cu
This test tool will replace iscsi-test which will remain but will not
be expanded with any new tests.
Other changes include:
- Add new CUnit based test tool: iscsi-test-cu to replace iscsi-test
- Add tests for persistent reservation
- Autotools updates
- Add pkgconfig
