4

I use xfs_freeze to freeze and unfreeze my xfs filesystem: 

xfs_freeze -f /blahblah

xfs_freeze -u /blahblah

After I run the unfreeze command I want to make sure that the filesystem is not frozen for sure. This command does not return any value or message.

I know I can try remounting the filesystem but that one is not full-proof.

Also if I run the unfreeze command again on an unfrozen filesystem I will get something like this: 

xfs_freeze: cannot unfreeze filesystem mounted at /blahblah: Invalid
argument

This method is not fool-proof either because the message is not accurate.

Is there a command I can use that would tell me the freeze status of the filesystem, or is there a fool-proof method that I can use to determine this?

Any hint?

Rui F Ribeiro
  • 55,929
  • 26
  • 146
  • 227
kaptan
  • 285
  • 2
  • 12

2 Answers2

3

TL;DR:

While there is no direct way to query if a filesystem is frozen, you can abuse the fact that nested freezing attempts don't work. For example, I have an XFS filesystem mounted at /xfs_test:

[root@testvm1 ~]# mount | grep xfs_test
/dev/sdb1 on /xfs_test type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

[root@testvm1 ~]# xfs_freeze -f /xfs_test/      # Initial freeze
[root@testvm1 ~]# echo $?
0

[root@testvm1 ~]# xfs_freeze -f /xfs_test/      # Subsequent freeze attempt
xfs_freeze: cannot freeze filesystem at /xfs_test/: Device or resource busy
[root@testvm1 ~]# echo $?
1

The same analogy works for un-freezing or thawing the filesystem:

[root@testvm1 ~]# xfs_freeze -u /xfs_test/      # Same filesystem, currently frozen
[root@testvm1 ~]# echo $?
0

[root@testvm1 ~]# xfs_freeze -u /xfs_test/      # Thawed filesystem
xfs_freeze: cannot unfreeze filesystem mounted at /xfs_test/: Invalid argument
[root@testvm1 ~]# echo $?
1

I had to do some digging to find out if the frozen/thawed state query was possible. Although the technical details were a little beyond my understanding, this is what I have put together.

Freezing and thawing a filesystem was a feature initially built for XFS. It was eventually brought forward to the Linux kernel, allowing the functionality to work for other filesystems as well. As this LWN article explains:

Takashi Sato proposes taking an XFS-specific feature and moving it into the filesystem code. The patch would provide an ioctl() for suspending write access to a filesystem, freezing, along with a thawing option to resume writes.

...

Essentially the patch just exports the freeze_bdev() kernel function in a user accessible way.freeze_bdev() locks a file system into a consistent state by flushing the superblock and syncing the device. The patch also adds tracking of the frozen state to the struct block_device state field.

At this point, nested freezing and thawing were possible. As I understand it, a counter variable in the code kept track of the nested freezing and thawing attempts. The variable would increment when freezing, and decrement when thawing. Only when the counter was 0 would the filesystem actually thaw.

After that, I found this patch discussion from 2016, which is about adding a new ioctl call to query the filesystem's state: fs: add the FIGETFROZEN ioctl call. As far as I can tell, this patch has not been merged into the kernel.

The patch discussion provided a few key points:

And, besides, polling for frozenness from userspace is inherently racy - by the time the syscall returns, the information may be incorrect, so you can't rely on it for decision making purposes in userspace.

And then:

I [sic] quick dig shows nesting was intentionally broken more than 5 years ago in making the freeze ioctl work on btrfs.

This led me to the, ahem, solution shown above.

Yet another possibility is covered in this answer over at StackOverflow. If you try to remount a filesystem which is frozen, the attempt will fail with a 'device is busy' error. The mount could also be busy for a number of other reasons, so this solution is admittedly not fool-proof.

Haxiel
  • 8,201
  • 1
  • 20
  • 30
  • 1
    While the mount could be busy for a number of other reasons, the filesystem being frozen is about one of the only ones that most people are likely to encounter that will cause a `mount -o remount` to fail with `-EBUSY`. – Austin Hemmelgarn Dec 07 '18 at 20:49
  • @kaptan Much appreciated. If my answer works for you, please do remember to upvote and/or accept it. – Haxiel Dec 13 '18 at 06:04
  • @Haxiel I have already upvoted. Let me implement your solution and see how it goes. – kaptan Dec 15 '18 at 00:00
0

I think you will have to write your own command that will check.

#!/bin/bash

function touchFs() {
    echo "mp: $1";
    touch "$1/frzn-5tst";
    if [ -f "$1/frzn-5tst" ]; then
            rm "$1/frzn-5tst" &> /dev/null;
    fi
}

function usage() {
    echo "$0 <mountpoint>";
    exit 1;
}

if [ -z $1 ]; then
   usage;
fi

touchFs $1&
ppid=$!;
state=`ps -o s= -p $ppid`;

if [ -z "$state" ]; then
    echo "device is unfrozen";
elif [ "$state" == "S" ]; then
    echo "device is frozen";
fi
NiteRain
  • 308
  • 1
  • 5