在ITPUB上看到这样一个案例,在一套Linux的RAC环境中,一个OCFS卷的inode节点已经用完,但是数据库仍然能够正常运行。
文件可以正常创建,该系统的几本情况大致如下:
以下为具体显示,/U04仅仅存放两节点产生的归档日志
最后作者从Metalink上找到了解释,也就是说OCFS和通常的文件系统不同,inodes在这里并不发挥通常文件系统的作用。
这是OCFS的特性,是正常的。
引用一点解释记录如下:
-The End-
文件可以正常创建,该系统的几本情况大致如下:
OS:LINUXAS3 U3
ORACLE:ORACLE9204 RAC
以下为具体显示,/U04仅仅存放两节点产生的归档日志
[root@db1 /]# cat /etc/issue
Red Hat Enterprise Linux AS release 3 (Taroon Update 3)
[root@db1/]# rpm -qa |grep ocfs
ocfs-support-1.0.10-1
ocfs-tools-1.0.10-1
ocfs-2.4.21-EL-smp-1.0.13-1
[root@db1 /]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/emcpowerd1 50G 44M 50G 1% /u04
[root@db1 /]# df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/emcpowerd1 409580 409231 349 100% /u04
最后作者从Metalink上找到了解释,也就是说OCFS和通常的文件系统不同,inodes在这里并不发挥通常文件系统的作用。
这是OCFS的特性,是正常的。
引用一点解释记录如下:
@ OCFS does not have the concept of inodes, however, for the vfs layer in the
@ kernel we need to fill out structures. the number returned by df -i is
@ based on diskspace free. it's the number of clusterblocsk in the filesystem
@ we dont' preallocate inodes like most filesystems do. nor do we HAVE to do
@ that. not a bug, expected behaviour, not required to do what any other
@ filesystem does.
-The End-
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




