Alastair Neil wrote: <snip> > > I succeeded in getting wireshark in stalled on the linux target server > and did a capture from there (attached). I'm not an expert but this > jumped out at me as a likely cause: > > > 8.784473 192.168.0.135 -> 192.168.0.45 iSCSI SCSI: Persistent > Reserve In LUN: 0x00 > 8.784859 192.168.0.45 -> 192.168.0.135 iSCSI SCSI Response (Check > Condition) LUN:0x00 [Unreassembled Packet [incorrect TCP checksum]] > 8.850272 192.168.0.135 -> 192.168.0.45 TCP 49622 > iscsi-target > [ACK] Seq=1737 Ack=19641 Win=277384 Len=0 TSV=2601 TSER=798756713 <snip> > It looks like a patch to support support for persistent reservations in > the linux kernel was submitted in January 30th this year so it is likely > that this is simply an unsupported feature at the moment. My question > is now will this cause problems? Is there a way to disable the > behaviour in the initiator? > > > Thanks, Alastair Neil
Hi Alastair, those commands "Persistent Reserve In" are likely sent by the initiator to test if the targets support persistent reservations. I don't think it is a problem that your targets do not support it. I wonder what is the actual problem. Is it just appearance of those messages about not enough sense information? Are you eventually able to use the iSCSI disks? The net traffic dump you attached suggests that at least the login phase was successful. Anyway, to investigate if some sense data were corrupted you need more verbose output from wireshark. The information you are looking for is on SCSI layer. As there are no Request Sense commands then probably autosensing is used. Hence try to look at responses with Check Condition if they contain valid sense data. Wireshark also supports import from Solaris' snoop(1M) output. So you can analyze network traffic on the initiator side as well. Use this command to do that: snoop -x 0 -d <interface> -o <output file> Another option for tracing SCSI commands is to use nice scsi.d dtrace script http://blogs.sun.com/chrisg/entry/scsi_d_script Regards, Milos _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
