[Pacemaker] iscsi migration to slow (disk errors) what to do ...

Florian Haas florian.haas at linbit.com
Wed Jun 15 11:17:59 EDT 2011


On 2011-06-15 15:08, Jelle de Jong wrote:
> root at 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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110615/6dd0fd57/attachment-0003.sig>


More information about the Pacemaker mailing list