我有一个报告文件系统已满的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 -oi /u03 Filesystem iused ifree %iused Mounted on /dev/md/dsk/d6 29663278 4230866 88% /u03
所以我想也许有些进程是保存打开的文件描述符（s）到20 + GB删除的文件。 但是，按照大小sorting，超过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，或任何其他任何人的想法。 重新启动该框或closuresoracle不是有效的调查选项。
编辑 ：哈立德，我当时不能。 我不能发布输出，因为其中一个数据库pipe理员已经释放了大约4GB，这意味着机器可以继续运行，如果我再次填充它作为一个testing，事情就会中断。 但这是24小时内的第二次，大约有92％已经满了，“填满”了（如新文件无法创build， /var/adm/messages报告“文件系统已满”），而且是，当它发生时，它肯定会破坏FS上文件的创build或扩展。
检查nbfree值
fstyp -v | head -18
如果说这个价值很低， 我发现这个博客文章可能会帮助你。 我引用这个post的开头：
在工作中，我们有一个带有UFS的Solaris 8，告诉应用程序它不能创build新文件。 如果自由inode，df命令显示出很多，并且FS中还有足够的空间。 应用程序得到错误的原因是，虽然在那里仍然有足够的碎片，没有空闲块可用了。 您不能仅创build一个带有碎片的新文件，每个新文件至less需要一个空闲块。
要查看UFS的空闲块的数量，您可以调用“fstyp -v |” 头-18“，看看”nbfree“背后的价值。