On 2011-06-15 15:08, Jelle de Jong wrote: > root@hennessy:~# dmesg > [56951.585704] device-mapper: snapshots: Snapshot is marked invalid. > [56951.590679] Buffer I/O error on device dm-24, logical block 0 > .. > [57077.664125] connection1:0: detected conn error (1020) > > root@hennessy:~# lvscan > /dev/dm-24: read failed after 0 of 4096 at 4294901760: Input/output error > /dev/dm-24: read failed after 0 of 4096 at 4294959104: Input/output error > /dev/dm-24: read failed after 0 of 4096 at 0: Input/output error > /dev/dm-24: read failed after 0 of 4096 at 4096: Input/output error
Still, that shouldn't happen ... unless your DefaultTime2Retain actually did expire in the meantime. If you're doing this during the resource migration, lvscan should instead block until either the connection is reinstated, or the Time2Retain timeout expires. You may want to run a "tcpdump -s0 -w /tmp/iscsi.pcap" while your connection is being initiated, and then run that pcap file through Wireshark. It comes with a nice protocol dissector for iSCSI, and you should be able to examine the negotiation process that way. Just to see whether the target and initiator really settle on the DefaultTime2Retain you want. Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
