Bug 126952

Summary:	Can't unfreeze GFS filesystem with outstanding write request
Product:	[Retired] Red Hat Cluster Suite	Reporter:	Derek Anderson <danderso>
Component:	gfs	Assignee:	Ken Preslan <kpreslan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Cluster QE <mspqa-list>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4	CC:	ccaulfie
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-01-10 17:27:46 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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

Verified.

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