Hei all 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? 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. So, again, sorry if this is slightly off-topic, I haven''t tried with OI, only S10u9, but still, I think it might be relevant, and right now, I''m a little desperate... Vennlige hilsener / Best regards roy -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk.
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. 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. > > So, again, sorry if this is slightly off-topic, I haven''t tried with OI, only S10u9, but still, I think it might be relevant, and right now, I''m a little desperate... > > Vennlige hilsener / Best regards > > roy > -- > Roy Sigurd Karlsbakk > (+47) 97542685 > roy at karlsbakk.net > http://blogg.karlsbakk.net/ > -- > I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk. > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> > 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. > > 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:Thanks a bunch. Now, it really shouldn''t be a 2TB boundary problem. We''ve been using this Sanrad thing for far larger volumes, and we have larger volumes in production too, which work, so I''m starting to think maybe the Sanrad is indeed the problem. The storage units (NexSAN stuff) don''t show any bad drives, so I somewhat doubt that''s the problem. Vennlige hilsener / Best regards roy (who can''t wait till he gets this proprietary shite kicked out) -- Roy Sigurd Karlsbakk (+47) 97542685 roy at karlsbakk.net http://blogg.karlsbakk.net/ -- I all pedagogikk er det essensielt at pensum presenteres intelligibelt. Det er et element?rt imperativ for alle pedagoger ? unng? eksessiv anvendelse av idiomer med fremmed opprinnelse. I de fleste tilfeller eksisterer adekvate og relevante synonymer p? norsk.
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