Bug 126952 - Can't unfreeze GFS filesystem with outstanding write request
Summary: Can't unfreeze GFS filesystem with outstanding write request
Alias: None
Product: Red Hat Cluster Suite
Classification: Retired
Component: gfs   
(Show other bugs)
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ken Preslan
QA Contact: Cluster QE
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-29 18:29 UTC by Derek Anderson
Modified: 2010-01-12 02:53 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-10 17:27:46 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Derek Anderson 2004-06-29 18:29:48 UTC
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.

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

Comment 1 Christine Caulfield 2004-07-21 12:38:53 UTC
This also seems to happen when using gulm as the lock manager.

Comment 2 Ken Preslan 2004-10-27 20:45:52 UTC
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.

Comment 3 Derek Anderson 2004-11-23 16:01:56 UTC
This is version 4.

Comment 4 Derek Anderson 2005-01-03 20:42:16 UTC
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

Comment 5 Ken Preslan 2005-01-03 23:11:10 UTC
This is a bug in the way "gfs_tool [freeze|unfreeze|withdraw]" works
with device mapper targets.  It should be fixed now.

Comment 6 Ken Preslan 2005-01-05 01:38:53 UTC
This should be fixed.  Reopen if you have problems.

Comment 7 Derek Anderson 2005-01-10 17:27:46 UTC

[root@link-11 /]# gfs_tool -V
gfs_tool 6.1-pre8 (built Jan  7 2005 17:08:37)

Note You need to log in before you can comment on or make changes to this bug.