Description of problem:
Three node setup with one filesystem.
Mounted the GFS on one node.
Issued a gfs_tool freeze /mntpt to the filesystem.
With the fs frozen ran 'cp /etc/hosts /mntpt'.
Issued 'gfs_tool unfreeze /mntpt'
Expected from previous behavior (6.0.0) that when the filesystem was
unfrozen the outstanding requests would be granted and traffic could
What I'm seeing is that the 'gfs_tool unfreeze /mntpt' command hangs
and never completes. Have to restart cluster to get back at the fs.
This is with the lock_dlm lock manager.
Version-Release number of selected component (if applicable):
[root@link-12 root]# gfs_tool -V
gfs_tool DEVEL.1088539777 (built Jun 29 2004 15:10:57)
Copyright (C) Red Hat, Inc. 2004 All rights reserved.
Steps to Reproduce:
This also seems to happen when using gulm as the lock manager.
Now, GFS freezes and unfreezes a filesystem by reading and writing to
/proc/fs/gfs instead of doing ioctl()s directly on GFS files. This
fixes a bug where a process trying to unfreeze a filesystem would end
up blocking behind another process holding a lock on the mountpoint
and waiting for the filesystem to be unfrozen. This bug has always
been present, but it's much more visible in the 2.6 code.
Note that the arguments to "gfs_tool [un]freeze" need to be exactly
what's found in /proc/mounts now.
This is version 4.
Arguments from /proc/mounts don't appear to be acceptable to gfs_tool.
[root@link-10 fs]# cat /proc/mounts | grep gfs
/dev/gfs/gfs1 /mnt/gfs1 gfs rw,noatime,nodiratime 0 0
/dev/gfs/gfs2 /mnt/gfs2 gfs rw,noatime,nodiratime 0 0
[root@link-10 fs]# gfs_tool freeze /mnt/gfs1
gfs_tool: unknown mountpoint /mnt/gfs1
[root@link-10 fs]# gfs_tool freeze /dev/gfs/gfs1
gfs_tool: unknown mountpoint /dev/gfs/gfs1
This is a bug in the way "gfs_tool [freeze|unfreeze|withdraw]" works
with device mapper targets. It should be fixed now.
This should be fixed. Reopen if you have problems.
[root@link-11 /]# gfs_tool -V
gfs_tool 6.1-pre8 (built Jan 7 2005 17:08:37)