[Linux-cluster] Fwd: GFS volume hangs on 3 nodes after gfs_grow

[Bob Peterson]

----- "Alan A" <alan.zg at gmail.com> wrote:
| I have been able to recreate the problem with gfs_grow. Here is the
| output
| of the test command, and the actual command, with the
| /var/log/messages -
| all from the node3. I am opening ticket with RH, and will give you
| the
| ticket number afterwards.
| 
| 
| [root at dev03 /]# gfs_grow -v -T /lvm_test2

Hi Alan,

This is helpful, thanks.  Please check that the clustered
bit is "on" for your volume group.  If you do the "vgs"
command, it should show "wz--nc" under "Attr" for the volume
group.  If not, (if it shows "wz--n-") it would explain your
problem, because it needs to be on.  So please, double-check
for me.  If the clustered bit is not on, the other nodes are not
informed by lvm of the resize that took place, so when gfs_grow
informs them of the file system size change, things don't go
well.  :7)

If the volume group is indeed clustered, it would help me a lot
to get a complete history of these commands pertaining to your GFS
volume:

lvcreate
lvresize or lvextend
mount
umount
gfs_mkfs or mkfs.gfs
gfs_fsck
gfs_grow

You might be able to grep these from the "history" command.
I just now created a logical volume of a similar size, and I was
able to do a gfs_grow on it without any problems, hangs or
consequences.  I must be doing something different, so I want
to make sure I hit the same conditions you hit by using the
exact same commands, if possible.  Otherwise, I'll have to
try a bunch of combinations and it may take be days to hit
the right combination.

Also, let me know what kind of activity was happening on the
other nodes while you were doing gfs_grow.  Not detailed; I
just want to know if the other nodes were likely to have been
writing to the file system.

Regards,

Bob Peterson
Red Hat Clustering & GFS