☰

文件系统已满 - 但事实并非如此

tag-icon • tag-icon filesystems solaris
文件系统已满 - 但事实并非如此

我有一个 Solaris 8 盒子，它报告文件系统已满：

db% tail -2 /var/adm/messages
Nov 22 08:32:27 db ufs: [ID 845546 kern.notice] NOTICE: alloc: /u03: file system full
Nov 22 08:34:51 db last message repeated 12 times

但是 df 说它没有用完可用的块，也没有用完可用的 inode：

db% df -k /u03
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/md/dsk/d6       282330903 254957403 24550191    92%    /u03
db% df -o i /u03
Filesystem             iused   ifree  %iused  Mounted on
/dev/md/dsk/d6      29663278 4230866    88%   /u03

因此，我认为也许某个进程将打开的文件描述符保留在 20+GB 的已删除文件上。但是 lsof 按大小排序时，报告的文件大小不超过 2GB，这是一个合法文件：

db% lsof /u03 | sort -n +6
COMMAND     PID     USER   FD   TYPE DEVICE   SIZE/OFF     NODE NAME
[...]
oracle     1257   oracle  278u  VREG   85,6 2097160192  9685782 /u03/oradata/(redacted)/data/foo_tab_14.dbf
db%

我很感激任何指向其他资源的指针，除了空闲块和 inode，它们的耗尽会填满文件系统，或者其他“隐藏”已用块/inode 的方法，或者任何其他想法。重新启动此框或关闭 oracle 不是有效的调查选项。

编辑：Khaled，我当时无法这样做。我无法发布输出，因为其中一个 DBA 释放了大约 4GB，这意味着机器可以继续运行，如果我再次“填满”它作为测试，事情就会中断。但这是 24 小时内第二次达到约 92% 的容量并“填满”（即无法创建新文件，并/var/adm/messages报告“文件系统已满”），是的，当这种情况发生时，它肯定会破坏该 FS 上的文件创建或扩展。

答案1

nbfree使用以下方法检查值

fstyp -v | head -18

如果这表示某种低价值，我发现的这篇博文可能会对你有帮助。我引用了这篇文章的开头：

在工作中，我们有一台带有 UFS 的 Solaris 8，它告诉应用程序它无法创建新文件。df 命令显示有大量的空闲 inode，并且 FS 中也有足够的空闲空间。应用程序出现错误的原因是，虽然仍有大量空闲的碎片，但没有可用的空闲块了。您不能仅使用碎片来创建新文件，每个新文件至少需要一个空闲块。

要查看 UFS 的空闲块的数量，您可以调用“fstyp -v | head -18”并查看“nbfree”后面的值。

相关内容