TL;DR：
虽然没有直接的方法来查询文件系统是否被冻结，但您可以滥用嵌套冻结尝试不起作用的事实。例如，我在/xfs_test上安装了一个XFS文件系统：
代码语言：javascript运行复制[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同样的类推适用于解冻或解冻文件系统：
代码语言：javascript运行复制[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我不得不做一些调查，以确定冻结/解冻状态查询是否可行。虽然技术细节超出了我的理解，但这就是我所做的。
冻结和解冻文件系统是最初为XFS构建的特性。它最终被引入到Linux内核中，允许该功能也适用于其他文件系统。正如这篇LWN文章所解释的：
Takashi Sato建议采用XFS特有的特性，并将其移动到文件系统代码中。该修补程序将提供一个ioctl()，用于暂停对文件系统的写访问，冻结，以及一个恢复写入的解冻选项。..。实际上，修补程序只是通过刷新超级块并同步设备，在用户可访问的freeze_bdev()中导出way.freeze_bdev()内核函数，从而将文件系统锁定为一致状态。修补程序还将对冻结状态的跟踪添加到struct block_device状态字段中。
在这一点上，嵌套冻结和解冻是可能的。据我所知，代码中有一个计数器变量跟踪嵌套的冻结和解冻尝试。该变量在冻结时增加，在解冻时减少。只有当计数器为0时，文件系统才会真正解冻。
之后，我发现了2016年的补丁讨论，它是关于添加一个新的ioctl调用来查询文件系统的状态：fs:添加FIGETFROZEN ioctl调用。据我所知，这个补丁还没有被合并到内核中。
补丁讨论提供了几个要点：
此外，从用户空间中轮询冻结性本质上是不正确的--当syscall返回时，信息可能是不正确的，因此您不能在用户空间中依赖它来进行决策。
然后：
我快速挖掘显示，嵌套是在5年多前在btrfs上使冻结ioctl工作时故意破坏的。
这让我找到了上面所示的解决方案。
还有一种可能性是在这是StackOverflow的答案中涵盖的。如果您试图重新装入已冻结的文件系统，则如果出现“设备繁忙”错误，该尝试将失败。安装也可能因为许多其他原因而繁忙，因此这个解决方案是不可否认的。