values that are put into it are defined as hexadecimal. This is a bit
confusing (grepping through the code for 251658241 did not result in
anything while the hex variant f000001 resulted in SCSI_STATUS_ERROR).
Originally, we use this in scsi-lowlevel.c only, this works as static
function. It also could be used to dump ISCSI opcode, so move it into
common utils.h/utils.c.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Describe the reason again:
A WRITE16 command[w] handles R2T, and queues DATAOUT PDU m,x,y,z:
outqueue->DATAOUT[x]->DATAOUT[y]->DATAOUT[z]...
outqueue_current->DATAOUT[m]
waitqueue->WRITE16[w]...
1, Once x, y, z gets released in initiator side, the target still expects the remaining
DATAOUT PDUs.
2, Once command w timeout and callback to uplayer, uplayers usually releases memory of
iscsi task(include memory referenced by iovec.iov_base). DATAOUT[m] would access
invalid memory iovce.iov_base.
So invoke WRITEx command callback until draining DATAOUT PDUs.
Co-developed-by: Rui Zhang <zhangrui.1203@bytedance.com>
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Once error occurs on socker read/write, libiscsi tries to reconnect
silently. Add necessary log message for this case.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Now we have more friendly opcode message once error occurs:
libiscsi:1 command timed out from waitqueue [...]
libiscsi:2 PDU header: 01 c1 ... e9 88[READ16] 00 00 00 ...
^(human readable opcode string)
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Distinguish command timeout from outqueue or waitqueue. For example,
A command sequence: ...NOP,READ,WRITE...
NOP OUT command has no dependence on backend media, it is expected to
response soon. Once NOP timeout in libiscsi:
a, the command is already sent to target, the target side does *not*
response.
b, the command is still pending in libiscsi.
Separate the two cases for trouble shooting.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
Users need to check if a task is queued to send (not sent yet)
before invoking functions such as iscsi_task_mgmt_abort_task_async.
Otherwise, because task management requests are automatically
treated as "immediate", a request to abort a task is sent before
the task itself.
if (iscsi_scsi_is_task_in_outqueue(iscsi_, task_)) {
iscsi_scsi_cancel_task(iscsi_, task_);
} else {
iscsi_task_mgmt_abort_task_async(iscsi_, task_, AbortCb, context_);
}
The blocks may exceed the block limits offered by the target,
query unmap/write zero max blocks by inquiry
SCSI_INQUIRY_PAGECODE_BLOCK_LIMITS command, than use a loop to do the
job.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
The new tool 'iscsi-md5sum' is used to calculate MD5 value of an iSCSI
target. This help users to verify data at range [LBA, Length).
For example, double-write on a RAID1 of 2 iSCSI targets, a daemon
process runs iscsi-md5sum to check data periodically.
Originally, we have to use several steps to achieve:
1, use iscsiadm to login.(root privilege required)
2, use dd(dd if=/dev/sdX of=/TMPPATH bs=4k count=LENGTH skip=LBA)
to dump data. (root privilege required, additional disk space required)
3, use md5sum to calculate MD5 value
4, remove data.
Instead, a single command iscsi-md5sum without root privilege is enough.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
The new tool 'iscsi-discard' is used to excute unmap or write zeros
on an ISCSI target. The parameters look like the command 'blkdiscard'
(from util-linux).
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
HEX format is friendly to iSCSI utils, for example:
./iscsi-inq -e 0x1 -c 0xb1 iscsi://...
atoi supports decimal only, this example does not work.
Use strtol(nptr, NULL, 0) to auto-detect format, then this works fine.
Signed-off-by: zhenwei pi <pizhenwei@bytedance.com>
When execute iscsi_task_mgmt_lun_reset_async function,
pdus are already removed from waitpdu list. In iscsi_service
function, this will call iscsi_process_pdu and release
pdu from waitpdu again, which cause segmentation fault.
Whether waitpud list is NULL should be checked here to avoid
the problem.
Signed-off-by: geruijun <geruijun@huawei.com>
