Red Hat Bugzilla – Bug 187073
lock_gulmd GenerationID mismatch at startup, cannot mount the GFS filesystem
Last modified: 2009-04-16 16:02:49 EDT
Description of problem:
On my 5-nodes cluster, I'm able to mount my GFS filesystem on 4 nodes, but on
sam56, mount blocks ("ps" show it is in state "D").
My nodes are named sam12, sam16, sam17, sam56 and sam57.
Version-Release number of selected component (if applicable):
GFS-18.104.22.168-0 on 5 nodes (2 nodes are x86_64, 3 nodes are i686)
Just one time. When I reboot all the cluster, it works again.
Steps to Reproduce:
1. start GFS on 5 nodes
With "gulm_tool nodelist localhost", I see:
- that all nodes except sam56 think that
1/ sam12 is the master
2/ sam16, sam17, sam57 are slaves
3/ sam56 is not in the list
- sam56 think that sam16 is arbitrating.
sam56 is unable to mount the GFS filesystem.
sam56 is able to mount the GFS filesystem like others nodes.
Created attachment 126886 [details]
Created attachment 126887 [details]
Created attachment 126888 [details]
It appears the problem occured because sam56 thought that sam16 was the master,
but sam16 actually became a slave to sam12. A workaround to this problem is to
just restart lock_gulmd on sam56. I'll work on a patch to fix this issue.
This should not be occuring any more w/ the latest GFS. Please re-open if this
becomes an issue.