Bug 210522 - Multiple freezes require multiple unfreezes
Multiple freezes require multiple unfreezes
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: gfs (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ryan O'Hara
GFS Bugs
Depends On:
  Show dependency treegraph
Reported: 2006-10-12 14:25 EDT by Steve Bonneville
Modified: 2010-01-11 22:13 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-10-12 10:38:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Steve Bonneville 2006-10-12 14:25:27 EDT
Description of problem:
If gfs_tool freeze is run multiple times from the same node against the
same GFS filesystem, gfs_tool unfreeze needs to be run the same number
of times to unfreeze the filesystem.  Is this intentional?

If it is intentional, is there a way to determine how many times a 
particular filesystem has been frozen, and from which nodes?

Version-Release number of selected component (if applicable):
Comment 1 Ryan O'Hara 2006-11-07 13:37:34 EST
It appears to be intentional, although I am not sure why.

When a freeze occurs, a counter in the in-core superblock is incremented. When
the unfreeze occurs, it is decremented. Simple, but this does mean that for
every freeze you do you must call an unfreeze. As I said, I am unsure why we do

It would be easy to fix, but I first need to determine if there is a valid
reason for it working the way it does now.

As for a way to find out how many times a filesystem has been frozen ... there
does not appear to (currently) be a way to do this. It would be nice to be able
to 'cat /proc/fs/gfs' to get this info. I am looking into the possibility of
adding this interface.

Comment 2 Steve Bonneville 2006-11-07 15:00:44 EST
If you do determine a valid reason for freeze working the way it does now,
please let me know that as well.  (Then we can document it in the GLS course to
help handle the customer/student question of why freeze works like this.)  :)
Comment 3 Ryan O'Hara 2006-11-13 14:39:29 EST
This is by design. The reason is as follows:

Say you have two processes, A and B. Process A freezes a filesystem and
continues processing, perhaps doing a backup of the filesystem. Before A
completes, process B decides to freeze the same filesystem. (Note: process A and
B are on the same node, of course.) Process B continues to do whatever it does,
and process A finishes and does an unfreeze. Note that B still expects that the
filesystem is frozen. If freeze/unfreeze was designed *not* to
increment/decrement a freeze counter, the unfreeze done by A will prematurely
unfreeze the filesystem (since B still expects that it is frozen).

I've added code to include the value of the sd_freeze_count when displaying the
filesystem counters. This can be seen by doing a 'gfs_tool counters
<mountpoint>' command. Its listed as "freeze count".

Note that because the value of these counters is retrieved via an ioctl command,
this is not possible in GFS2, since most/all <?> of the ioctl code was removed.
I added the change for GFS(1) for RHEL4 and RHEL5.
Comment 4 Steve Bonneville 2006-11-13 14:59:32 EST
That rationale sounds quite reasonable.

It seems to me that what's left here is just to figure out if there's some way
to make the GFS2 freeze counter information available in case some sysadmin is
attempting to debug an issue where a process fails to issue unfreeze properly.
Comment 5 Ryan O'Hara 2006-11-13 15:07:28 EST
Yes. If we want to do something similar for GFS2 we will probably have to read
it via sysfs. I can see where getting to value of this counter would be quite

Comment 6 Alasdair Kergon 2006-11-15 12:03:42 EST
It's an open question whether or not freeze/thaw bdev functions should maintain
such a counter: currently they don't.  Can we avoid multiple counters?  How many
entry points are there for a freeze request?

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