Wandering Thoughts archives

What an iSCSI Enterprise Target kernel message really means

IET is the Linux iSCSI target implementation that we use. Periodically it will spit out somewhat alarming kernel messages that look like this:

iscsi_trgt: scsi_cmnd_start(1045) Unsupported 15
iscsi_trgt: cmnd_skip_pdu(454) e0da9005 1c 15 32

(The numbers in brackets will vary from IET version to version; they are line numbers in the source code of IET's kernel module.)

What this actually means is best summarized as 'iscsi_trgt: unsupported or unimplemented SCSI opcode 0x15'. How important this is depends on what SCSI opcode 0x15 turns out to be and how much your initiator machine cares about having it supported (and what happens if it's not). Sometimes everything will go on without problems, but at other times this is the prelude to a nasty explosion because your initiator really does need that particular SCSI operation.

The most convenient breakdown that I know of for what SCSI opcode has what hex value is include/scsi/scsi.h in the Linux kernel source; you can see it online here. Or there's also the handy Wikipedia page (silly me for not looking there before now), which even links to explanations of some of the opcodes.

The ones that I've seen in our environment are:

• 0x15 (MODE SELECT); sent by ZFS to try to turn on disk write caches. IET doesn't support the initiator changing whatever write caching the target has set up (or any of the other things theoretically settable in SCSI mode pages).

• 0x4d (LOG SENSE), presumably because the Solaris initiator is trying to check for disk errors. Fortunately we are already doing that on the iSCSI backends (well, usually).

• 0x5e (PERSISTENT RESERVE IN); this is a query, so the Solaris initiators may be trying to see if there is cluster storage fencing in effect.

So far, none of these have turned out to be essential for us.

(The situation with ZFS, IET, and write caches is beyond the scope of this entry, but ZFS's inability to nominally enable the nominal disk write caches is not currently a problem for us.)

Sidebar: the exact format of this message

For my future reference: the number after the Unsupported is the SCSI opcode byte, in hex. The cmd_skip_pdu numbers are all in hex and are, in order, the command's initiator task tag (ITT), the command's iSCSI opcode, the SCSI opcode byte, and the iSCSI PDU's data size. The names are the names of the functions in the IET kernel module that print these errors (and as mentioned, the number in the brackets is the line number in the source code).

(Note that iSCSI opcodes are not the same thing as SCSI opcodes. Welcome to the 'enterprise' madness that is iSCSI.)

iSCSI opcodes probably mean something to people who know the protocol, but for people like me they are basically opaque and probably unimportant. The IET source has a list of them in kernel/iscsi_hdr.h, augmented with some aliases by kernel/iscsi.h.