valgrind does not know that sense will be initialized by the ioctl
so we need to to it explicitely to keep it from warning us.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Create a wrapper for sending scsi_commands so that we can hide the
libiscsi function far away from the "opcode" helpers.
This means we only have a single place later to switch to a different
type of device, such as a SG_IO one.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Switch orwrite helpers to use _command_async instead of calling _orwrite_sync()
to prepare for switching to non-iscsi targets. Use the new check_result API
so that we only need a single helper function for ORWRITE instead of one
helper for each expected result.
Signed-off-by: Ronnie Sahlberg <sahlberg@localhost>
Many/most all SCSI helpers do pretty much the same checking for the SCSI
result and status. Break this out into a separate helper that we can use
to reduce code duplication.
Signed-off-by: Ronnie Sahlberg <sahlberg@localhost>
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>
