Bug 126952 - Can't unfreeze GFS filesystem with outstanding write request
Can't unfreeze GFS filesystem with outstanding write request
Status: CLOSED CURRENTRELEASE
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ken Preslan
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-29 14:29 EDT by Derek Anderson
Modified: 2010-01-11 21:53 EST (History)
1 user (show)

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


Attachments (Terms of Use)

  None (edit)
Description Derek Anderson 2004-06-29 14:29:48 EDT
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
resume.

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:
Always.

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Christine Caulfield 2004-07-21 08:38:53 EDT
This also seems to happen when using gulm as the lock manager.
Comment 2 Ken Preslan 2004-10-27 16:45:52 EDT
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 11:01:56 EST
This is version 4.
Comment 4 Derek Anderson 2005-01-03 15:42:16 EST
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 18:11:10 EST
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-04 20:38:53 EST
This should be fixed.  Reopen if you have problems.
Comment 7 Derek Anderson 2005-01-10 12:27:46 EST
Verified.

[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.