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

10

尝试在客户端盒上安装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    -
boot  disk-usage  rm  opensolaris 
— 尼克·法拉第
source
1
它看起来好像正在写入日志的文件系统或池已满。服务器上的文件系统和磁盘组织是什么？您仍然可以登录到服务器吗（您似乎在说不，但随后又说您已尝试删除文件）？什么是你的意思“这给了我一个没有空间的错误，当我尝试和删除任何”：什么命令究竟是不是您键入的，什么确切的错误信息弄来？
— 吉尔（Gilles）“所以，别再邪恶了”，
更新的帖子以回答您的问题
— Nick Faraday
好。所以，请张贴的输出df和mount。您对该服务器的配置了解多少？特别是有关其日志记录配置的信息？
— 吉尔斯（Gilles）'所以
更新并添加了所需的输出数据...感谢您的关注！
— 尼克·法拉第
请添加zfs list -t all
— jlliagre 2011年

Answers:

13

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

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

原因是快照中仍然存在您要删除的文件。因此，删除它时，内容将保持存在（仅在快照中）；并且系统还必须另外写入快照包含文件但当前状态没有的信息。没有多余的空间来存储这些额外的信息。

短期修复是找到在最新快照之后创建的文件并将其删除。另一种可能性是找到在最新快照之后附加到的文件，并将其截断为最新快照时的大小。如果磁盘已满，是因为某些内容一直在浪费日志，请尝试修剪最大的日志文件。

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

此OpenSolaris论坛线程中对此问题进行了广泛的讨论。

— 吉勒斯“别再邪恶了”
source
3
快照功能不是问题的根源-请参阅下面的答案。但是如您所正确描述的那样，能够发布快照可以解决奇迹：)
— Tatjana Heuser 2012年
8

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

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

摆脱困境的方法：

  • 释放快照（如果有一个...）
  • 增加池（以防万一，您可以分配给池）
  • 销毁池中的另一个文件系统，然后扩展紧的文件系统
  • 截断文件，然后将其删除（尽管一旦我挤得太紧，甚至无法做到这一点，请参阅ZFS Discuss上的线程）
  • 取消链接文件。（同上）

几年前，我遇到了同样的陷阱，没有释放任何快照可以释放我。请参阅ZFS讨论中讨论该问题的线程。

— 塔塔娜·赫瑟（Tatjana Heuser）
source
1

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

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

— 耶利亚格雷
source
ya应该是2而不是az（OCR'd img）。当我CD到/ rpool那里什么都没有时，这很奇怪吗？我认为“维护模式”无法建立正确的链接！/ export也没有。
— 尼克·法拉第
admin应该安装在/ export / home / admin上，而不是/ rpool上。如果它不在维护模式，则可以手动安装它。
— jlliagre 2011年
0

我已经有了，花了一段时间试图找出需要的东西。我的解决方案是在尝试删除文件之前将文件的空间清零。

我们有一些行为异常的过程，有时会发疯，并在磁盘中填充核心文件（以数字结尾），因此我制作了一个脚本，其中包含类似内容以保留一个副本。

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
— 用户名
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.