are in flight at the moment.
Aside from commands, we also consider the "has not yet connected completely" as being an i/o.
When this command returns 0 it means we are connected ant the iscsi connection is idle, with no commands in flight.
KVM needs a function to detect idleness like this for its block layer io_flush
function.
"random" ISID randomly.
Dont assume that users will never create multiple contexts
concurrently, in which case the previous getpid()^time(NULL)
would create duplicates.
iscsi-dd can be used to copy the content of one iscsi lun onto a different
iscsi lun of the exact same sixe.
This example illustrates how to "steal" a task structure from a callback
so we can use store it and have it remains valid after the read10 callback
has completed.
It also illustrates the async api of libiscsi for read10/write10.
Initially a number of read10 calls are made asynchronously until the
queue is full.
As each read10 completes and returns data, we issue a write10 to write
that data to the other lun.
As soon as a write10 completes, we "release" the initial read10 task corresponding to what we wrote and issue a new read10 to continue copying the next set of un-read data.
Using the async api, it should be easy to get very high performance and
throughput even from one single thread.
LBA is uint32_t for read/write10
Also store the lba/numblocks arguments in the task structure for read10/write10
This makes it much easier to implement a fully async "read lots/write lots"
applications.
A Portal URL is of the form
iscsi://[<username>[%<password>]@]<host>[:<port>]
and is used by command such as iscsi-ls during the discovery login phase.
During discovery we do not yet know the target iqn name, nor the lun of
any devices.
There is no point in setting the username if there is no password
and vice versa.
Also, if we only set username but not passwd this would lead to a segv.
so that the password will not be showing up in log where the application
logs the "filename/iscsi url" or in ps aux output.
LIBISCSI_CHAP_USERNAME and LIBISCSI_CHAP_PASSWORD environment variables are
available to set these outside of the url.
If hte username/password is ALSO set in the URL, the settings in the URL
will override the environment variables.
Update the "send scsi command" fucntion to honour
"FirstBurstLength" so that we only send this many bytes as unsolicited data.
The wait for a train of R2T from the target to clock out additional
busrts of data until the full task data has been sent to the Target.
We should now honour, and handle the case of
ImmediateData=No
InitialR2T=No
correctly for targets that are limited on receiveing data too fast.
Update the send pdu command to trap when we need to send data to the target
but we are not allowed to send using immediate data.
For this case, send the data as a separate DATAOUT pdu instead.
Twiddle the flags and other fields to now manage that we send the data
as two separate PDUs.
This function can allocate a new pdu using a specific itt value
and specific flags instead of using the defaults of, next iff, no flags set.
This can be used when we need to allocate additional PDUs in a chain,
for commands that span across multiple PDUs and where all need to keep
the same itt value.
For example
->WRITE10 cdb
->DATAOUT
-<RESPONSE
Here the DATAOUT PDU belongs to the same task that was started by write10
so it need to use the same itt value.
This flag is used when we dont want the CANCEL callback to be invoked if the
context is destroyed.
Thsi will be used for the sequence where we send multiple PDUs
to the target for one single scsi task, such as
-> WRITE10 cdb
-> DATAOUT
-< RESPONSE
Since if the context is destroyed when the command is in flight, we
already get the CANCEL callback for the WRITE10 PDU, so we dont need to invoke
it again for when we destroy the DATAOUT pdu, since they both refer to the same
task.
Add a new pdu flag : DELETE_WHEN_SENT. When this pdu has been
sent to the wire, the pdu will be deleted and not put on the waitpdu list.
This will be useful for sequences such as
-> WRITE10 cdb
-> DATAOUT the data to write
-< RESPONSE
Where we want to match WRITE10 and RESPONSE but where the plain DATAOUT pdu
will not be soliciting its own response.
We dont need to wait for the response to DATAOUT pdus, we are already waitin
for the response form the initial PDU in the sequence.
We will use this later to decide when we should send unsolicited imemdiate
data to the target. Currently we always send unsolicited immediate data
but targets configured to not allow immediate data may refuce this and
turn an error.
and accept what Target responds.
Store the result of the negotiated setting in the iscsi context
so we can use it later to determine how to send solicited/unsolicited
data.
Always print the correct url syntax when parsing has failed.
Test if the user forgot to specify a <target-iqn> at all and log
this as a missing target-iqn error. Not as a missing <lun> error.
Remove \n from the error strings in init.c
