在 OpenSolaris 下删除文件时设备上没有空间

Question 1

好吧，这很奇怪……没有足够的空间来删除文件！

事实证明，这是 ZFS 的一个相对常见的问题，尽管它可能会出现在任何文件系统上有快照。

解释是您尝试删除的文件仍然存在于快照中。因此，当您删除它时，内容仍然存在（仅在快照中）；并且系统必须额外写入快照有该文件但当前状态没有的信息。没有足够的空间容纳额外的一点信息。

短期修复方法是找到在最新快照之后创建的文件并将其删除。另一种可能性是找到在最新快照之后附加的文件，并将其截断为最新快照时的大小。如果您的磁盘由于某些内容向您的日志发送垃圾邮件而变满，请尝试修剪最大的日志文件。

更普遍适用的修复方法是删除一些快照。您可以使用列出快照zfs list -t snapshot。似乎没有一种简单的方法可以预测如果销毁特定快照将重新获得多少空间，因为它存储的数据可能会被其他快照所需要，因此如果您销毁该快照，数据将继续存在。因此，如有必要，请将数据备份到另一磁盘，识别不再需要的一个或多个快照，然后运行zfs destroy name/of/snap@shot.

对于这个问题有一个扩展的讨论这个 OpenSolaris 论坛主题。

Answer

好吧，这很奇怪……没有足够的空间来删除文件！

事实证明，这是 ZFS 的一个相对常见的问题，尽管它可能会出现在任何文件系统上有快照。

解释是您尝试删除的文件仍然存在于快照中。因此，当您删除它时，内容仍然存在（仅在快照中）；并且系统必须额外写入快照有该文件但当前状态没有的信息。没有足够的空间容纳额外的一点信息。

短期修复方法是找到在最新快照之后创建的文件并将其删除。另一种可能性是找到在最新快照之后附加的文件，并将其截断为最新快照时的大小。如果您的磁盘由于某些内容向您的日志发送垃圾邮件而变满，请尝试修剪最大的日志文件。

更普遍适用的修复方法是删除一些快照。您可以使用列出快照zfs list -t snapshot。似乎没有一种简单的方法可以预测如果销毁特定快照将重新获得多少空间，因为它存储的数据可能会被其他快照所需要，因此如果您销毁该快照，数据将继续存在。因此，如有必要，请将数据备份到另一磁盘，识别不再需要的一个或多个快照，然后运行zfs destroy name/of/snap@shot.

对于这个问题有一个扩展的讨论这个 OpenSolaris 论坛主题。

Question 2

这是写时复制文件系统的一个众所周知的问题：要删除文件，文件系统首先需要分配一个块并修复新状态，然后才能释放刚刚删除的文件中包含的大量空间。

（这是不是带有快照的文件系统的问题，因为除了写时复制之外还有其他实现这些的方法）

摆脱困境的方法：

发布一个快照（万一有的话……）
扩大池（如果有剩余的可以分配给它）
销毁池中的另一个文件系统，然后增长紧缩的文件系统
截断该文件，然后将其删除（尽管一旦我陷入了太紧的压力而无法做到这一点，请参阅ZFS 讨论中的线程）
取消文件链接。（同上）

几年前我也遇到过同样的陷阱，但没有任何可以发布的快照来释放我。请参阅线程ZFS讨论这个问题已经被深入讨论过。

Answer

这是写时复制文件系统的一个众所周知的问题：要删除文件，文件系统首先需要分配一个块并修复新状态，然后才能释放刚刚删除的文件中包含的大量空间。

（这是不是带有快照的文件系统的问题，因为除了写时复制之外还有其他实现这些的方法）

摆脱困境的方法：

发布一个快照（万一有的话……）
扩大池（如果有剩余的可以分配给它）
销毁池中的另一个文件系统，然后增长紧缩的文件系统
截断该文件，然后将其删除（尽管一旦我陷入了太紧的压力而无法做到这一点，请参阅ZFS 讨论中的线程）
取消文件链接。（同上）

几年前我也遇到过同样的陷阱，但没有任何可以发布的快照来释放我。请参阅线程ZFS讨论这个问题已经被深入讨论过。

Question 3

4.Z3G（rpool/root USED 列）是可疑的。

无论如何，rpool/export/home/admin 太大（3.85 GB）可能是根本原因。查看其内容并删除其中不必要的文件。由于管理文件系统没有快照，因此应该立即释放池中的一些空间。

Answer

4.Z3G（rpool/root USED 列）是可疑的。

无论如何，rpool/export/home/admin 太大（3.85 GB）可能是根本原因。查看其内容并删除其中不必要的文件。由于管理文件系统没有快照，因此应该立即释放池中的一些空间。

Question 4

我有了这个，并花了一段时间试图弄清楚需要什么。我的解决方案是在尝试删除文件之前将其空间清零。

我们有一些行为不当的进程，它们偶尔会变得疯狂，并用核心文件（以数字结尾）填充磁盘，因此我生成了一个包含类似内容的脚本来保留一个副本。

for file in core*[0-9]
do
    coreFile=${file%.[0-9]*}

    mv $file $coreFile
    if [[ $? == 0 ]]
    then
        chmod 644 $coreFile
    else
        truncate -s 0 $file # we can't just delete if disk is full so zero out first
        rm $file
    fi
done

当我运行我的脚本时，它产生了一个错误：

mv: cannot rename core.200000 to core: No space left on device

并可以清除文件。

为了测试这一点，我用以下内容填充了磁盘：

for ((ii=0; ii<100000; ii++))
do
    mkfile 1m core.$ii
done

Answer