On Mon, Sep 08, 2014 at 03:35:05PM +0000, Neale Ferguson wrote: > As for the gfs2 lockspace, Node 2 reports this when dealing with the checkpoint area: > > 1410147820 lvclusdidiz0360 set_plock_ckpt_node from 2 to 2 > 1410147820 lvclusdidiz0360 unlink ckpt 520eedd100000002 > 1410147820 lvclusdidiz0360 unlink ckpt error 12 lvclusdidiz0360 > 1410147820 lvclusdidiz0360 unlink ckpt status error 12 lvclusdidiz0360 > 1410147820 unlink ckpt 520eedd100000002 close err 12 lvclusdidiz0360 > 1410147820 lvclusdidiz0360 store_plocks r_count 45 p_count 63 total_size 2520 max_section_size 280 > 1410147820 lvclusdidiz0360 store_plocks open ckpt handle 6157409500000003 > 1410147820 lvclusdidiz0360 store_plocks first 66307 last 88478 r_count 45 p_count 63 sig 5ab0 Creating and writing the new checkpoint appears to have worked, despite the errors about unlinking the previous one. The problem may come after this when corosync attempts to transfer the checkpoint to the other node. > I'm still not groking the checkpoint process. Where is this checkpoint > information kept? The checkpoint data is sent to corosync/openais, which is responsible for syncing that data to the other nodes, which should then be able to open and read it. You'll also want to look for corosync/openais errors related to checkpoints. > Also, when I try an imitate the situation by holding a R/W lock and then > causing that node to restart without shutting down (and releasing the > lock), the other node purges the lock when it detects the failing node > has disappeared. I don't understand why the locks reported in the > previous mail aren't purged as well. The problem is almost certainly with the operation of the checkpoints, not with the locking. -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
