[Linux-cluster] Fwd: GFS volume hangs on 3 nodes after gfs_grow
alan.zg at gmail.com
Fri Sep 26 20:54:48 UTC 2008
Thank you bob for all the hard work. I am sorry for not being specific from
the get go.
Just a little info to some future readers - if you get:
"Skipping cluster volume group" - all you have to do is change
/etc/lvm/lvm.conf locking to type 3.
# Type of locking to use. Defaults to local file-based locking (1).
# Turn locking off by setting to 0 (dangerous: risks metadata corruption
# if LVM2 commands get run concurrently).
# Type 2 uses the external shared library locking_library.
# Type 3 uses built-in clustered locking.
locking_type = 3
Thanks all for the help.
On Fri, Sep 26, 2008 at 3:46 PM, Bob Peterson <rpeterso at redhat.com> wrote:
> ----- "Alan A" <alan.zg at gmail.com> wrote:
> | gfs_sda1 1 1 0 wz--n- 10.00G 5.00G
> | gfs_sdb1 1 1 0 wz--n- 10.00G 3.50G
> | The vg's are not enabled with the cluster bit. I am sorry for not
> | being more
> | informative on LVM. If I enable cluster bit with vgchange -c command
> | would
> | that convert the volumes to cluster volume group, or should I start
> | by
> | blowing them away?
> Hi Alan,
> It's perfectly fine to enable the clustered bit with vgchange -cy,
> and that flags the entire vg and all the lvs inside it.
> You should probably unmount-then-mount the gfs file system on all
> the nodes after that, just to be safe. I don't think you need to
> remount on the node that did the gfs_grow though.
> The missing clustered bit is probably the cause of all your grief,
> so I wouldn't bother opening a ticket, unless you can recreate
> the failure with the clustered bit on, after umount-then-mount.
> Bob Peterson
> Red Hat Clustering & GFS
> Linux-cluster mailing list
> Linux-cluster at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Linux-cluster