On Feb 26, 2011, at 1:04 PM, Jim Dunham wrote:
> Roy,
>
>> Sorry for crossposting, but I'm not really sure where this question belongs.
>>
>> I'm trying to troubleshoot a connection from an s10 box to a SANRAD iSCSI
>> concentrator. After some network issues on the switch, the s10 box seems to
>> lose iSCSI connection to the SANRAD box. The error messages I get in the
>> logs are pasted here http://pastebin.com/hyuuRvNt - we get tons of these and
>> the error block number seems to vary to the extremes, so I somewhat doubt
>> that's the issue.
>>
>> Now, the question is simple, where would you think the source of these
>> errors belong?
>
> Based on the log supplied, it would appear that the iSCSI Target from SANRAD
> is failing on the SCSI command 0x8a, being a SCSI Write(16) command.
Yes. Read this as: the SCSI target is responding to a Write(16) command with
the error message
"hardware error" (sense key 0x4) "logical unit not ready, manual intervention
required" (asc/ascq = 0x4/0x3)
I'd be surprised if there is anything you can do on the initiator side to fix
this.
For quick reference, the more common key codes are at:
http://en.wikipedia.org/wiki/Key_Code_Qualifier
A more complete list is available from t10.org
>
> A SCSI Write(16) command is required to read and write to SCSI LUNs that are
> equal to, or greater than 2TBs in size. The Check Conditions and resulting
> information give indications that I/Os to LBAs above the 2TB size are those
> that are failing.
>
> To validate this, performing I/Os at the 2TB boundary, or higher will trigger
> the use of Read(16) and/or Write(16) SCSI CDBs, and thus iSCSI I/Os between
> initiator and target. The can be done with dd(1m) as follows:
>
> dd of=/dev/rdsk/c?t?d?s0 if=/dev/rdsk/c?t?d?s0 seek=4294967296 count=1
>
> Note: Make sure that both devices specified (dev/rdsk/c?t?d?s0) are identical
> so that the data written is identical to the data read.
>
> - Jim
>
>
>> On the initiator or the target? I tried to setup a new server (initiator) to
>> eliminate that part, exported the two pools, and tried zpool import to look
>> for them again, but could only find one of them, even though I specified the
>> taret statically.
I find fmdump -eV output to be more descriptive, but that probably means I've
been spending
too much time dealing with broken targets :-)
-- richard
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
