The fsfreeze command, is used to suspend and resume access to a file system. This allows consistent snapshots to be taken of the filesystem. fsfreeze supports Ext3/4, ReiserFS, JFS and XFS.
A filesystem can be frozen using following command:
Now if you are writing to this filesystem, the process/command will be stuck. For example, following command will be stuck in D (UNINTERUPTEBLE_SLEEP) state:
Only after the filesystem is unfreezed using the following command, can it continue:
As per the fsfreeze main page, “fsfreeze is unnecessary for device-mapper devices. The device-mapper (and LVM) automatically freezes filesystem on the device when a snapshot creation is requested.”
fsfreeze is provided by the util-linux package in RHEL systems. Along with userspace support, fsfreeze also requires kernel support.
For example, in the following case, fsfreeze was used in the ext4 filesystem of an AWS CentOS node:
fsfreeze: /mysql: freeze failed: Operation not supported
From strace we found that ioctl is returning EOPNOTSUPP:
st_nlink=4, st_uid=3076, st_gid=1119, st_blksize=4096, st_blocks=8,
st_mtime=2014/11/17-01:39:36, st_ctime=2014/11/17-01:39:36}) = 0
ioctl(3, 0xc0045877, 0) = -1 EOPNOTSUPP (Operation not
From latest upstream kernel source:
struct super_block *sb = file_inode(filp)->i_sb;if (!capable(CAP_SYS_ADMIN))
/* If filesystem doesn’t support freeze feature, return. */
if (sb->s_op->freeze_fs == NULL)
/* Freeze */
EOPNOTSUPP is returned when a filesystem does not support the feature.
On testing to freeze ext4 in CentOs with AWS community AMI, fsfreeze worked fine.
This means that the issue was specific to the kernel of the system. It was found that AMI used to build the system was having a customized kernel without fsfreeze support.