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

Question

尝试在客户端上安装 NFS 共享（从OpenIndiana服务器导出）时，OI 服务器崩溃了。我得到了黑屏死机，看起来像日志转储，然后系统重新启动。它再也没有出现过，并且在我停止启动后收到以下错误消息：

svc.startd[9] Could not log for svc:/network/dns/mulitcast:default: write(30) failed with No space left on device?

除了操作系统之外，我的启动驱动器上没有其他任何东西，所以...我不确定是什么东西填满了驱动器？也许是某种日志文件？无论如何，我似乎无法删除任何内容。当我尝试删除任何内容时，它给了我一个没有空格的错误：

$ rm filename
cannot remove 'filename' : No space left on device 

我可以登录“维护模式”，但不能登录标准用户提示。

的输出df是：

rpool/ROOT/openindiana-baseline    4133493    4133493          0    100%   /
swap                              83097900      11028  830386872      1%   /etc/svc/volatile
/usr/lib/libc/libc_hwcap1.so.1     4133493    4133493          0    100%   /lib/libc.so.1

的输出mount是：

/ on rpool/ROOT/openindiana-baseline read/write/setuid/devices/dev:2d9002 on Wed Dec 31 16:00:00 1969
/devices on /devices read/write/setuid/devices/dev:8b40000 on Fri Jul 8 14:56:54 2011
/dev on /dev read/write/setuid/devices/dev:8b80000 on Fri Jul 8 14:56:54 2011
/system/contract on ctfs read/write/setuid/devices/dev:8c40001 on Fri Jul 8 14:56:54 2011
/proc on proc read/write/setuid/devices/dev:8bc0000 on Fri Jul 8 14:56:54 2011
/etc/mnttab on mnttab read/write/setuid/devices/dev:8c80001 on Fri Jul 8 14:56:54 2011
/etc/svc/volatile on swap read/write/setuid/devices/xattr/dev:8cc0001 on Fri Ju8 14:56:54 2011
/system/object on objfs read/write/setuid/devices/dev:8d00001 on Fri Jul 8 14:6:54 2011
/etc/dfs/sharetab on sharefs read/write/setuid/devices/dev:8d40001 on Fri Jul 14:56:54 2011
/lib/libc.s0.1 on /usr/lib/libc/libc_hucap1.s0.1 read/write/setuid/devices/dev:d90002 on Fri Jul 8 14:57:06 2011 

'zfs list -t all' 的输出是：

rpool                                                       36.4G   0       47.5K   /rpool
rpool/ROOT                                                  4.23G   0         31K   legacy
rpool/ROOT/openindiana                                      57.5M   0       3.99G   /
rpool/ROOT/openindiana-baseline                             61K     0       3.94G   /
rpoo1/ROOT/openindiana-system-edge                          4.17G   0       3.98G   /
rpool/ROOT/openindiana-system-edge@install                  19.9M   -       3 38G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:45:08      73.1M   -       3.57G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-06-20:48:53      75.9M   -       3 82G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:14:04      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:15:14      61K     -       3.94G   -
rpoo1/ROOT/openindiana-system-edge@2011-07-07-02:28:14      61K     -       3.94G   -
rpool/ROOT/openindiana-system-stable                        61K     0       3.94G   /
rpoo1/ROOT/pre_first_update_07.06                           108K    0       3 82G   /
rpool/ROOT/pre_second_update_07.06                          90K     0       3.57G   /
rpool/dump                                                  9.07G   0       9.07G   -
rpool/export                                                3.85G   0       32K     /export
rpool/export/home                                           3.85G   0       32K     /export/home
rpool/export/home/admin                                     3.85G   0       3.85G   /export/home/admin
rpool/swap                                                  19.3G   19.1G   126M    -

Answer 1

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

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

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

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

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

在此 OpenSolaris 论坛主题中对此问题进行了扩展讨论。

Answer 2

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

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

摆脱压力的方法：

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

几年前我也遇到过同样的陷阱，并且没有任何可以释放的快照来释放我。请参阅ZFS 讨论中已深入讨论此问题的线程。