I'm getting cmd_abort (1143) or cmnd_abort(1143) errors in my iSCSI system.
Symptom: The logs are reporting cmd_abort (1143) errors.
Problem: Not critical. Related to performance. The iSCSI command is timing out during data transfer. Common when using VMWare ESX; with ESX, the initiator is sending an unknown command to the target; no threat to the system or data.
The other proble could be that the iSCSI Enterprise Target (IET) took too long to perform a SCSI command and the Initiator timeout expired.
Solution: Several solutions can be tested, most related to improving performance. See below for details.
Additional information:
Set your VMalloc size to 384MB.
Go to the console tools:
Ctl-Alt-W
Select Tuning Options
Select VMalloc size: set to 384
Set your MaxXmitSegmentLength and MaxSendSegmentLength to the
maximum allowed: 65536 bytes.
If the 65536 bytes do not help, try seting it to the maximum allowed value of 262144
and set the MaxBurstLength to 16776192
Because the percentage of each block
required for overhead falls as the blocks get larger, max xmit is conventionally set as large as possible.
Procedure:
Go to the console tools:
Ctl-Alt-W
Select Tuning Options
Select iSCSI Daemon options
Select Target Options
Select a target
Set MaxRecvDataSegmentLength and MaxXmitDataSegmentLength to 65536.
Finally, you might want to elect to use Jumbo Frames. This will increase
individual packet size, thereby decreasing the number of frames that need to
be sent, reducing traffic on the network. Procedure:
Console Tools
Ctl-Alt-W
Select Tuning Options
Select Jumbo Frames config
Select your ethernet card
Set the Jumbo Frames number to 9000
Clear the metadata on all your Volume replication sources, remove your volume replication tasks and recreate them.
One possible cause of these errors is corrupt metadata.
Open-E software impacted: DSS, iSCSI R3, iSCSI enterprise
Example ticket number: