----- "Alan A" <alan.zg@xxxxxxxxx> 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@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 -- Linux-cluster mailing list Linux-cluster@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
