solaris下的inode

探讨一个UFS文件系统所允许创建的最大文件数zz

http://blog.sina.com.cn/s/blog_45d51ebc0100044x.html

Solaris操作系统下每个常规文件必须包含一个文件名和与之相关联的inode(信息节点),inode中存储文件的相关信息(如文件的所有者、权限和大小等信息),以及该文件所关联的数据块的指针.因此,inode数量的多少决定着一个UFS文件系统所允许创建的文件数.

一个UFS文件系统在其创建时,所允许最大的indoe数就已经固定,当该文件系统中有大量的(上千万甚至上亿个)小文件存在时,有可能出现inode数量不够用的情况,由于文件需要用inode来存储元数据(MetaData),inode数量超出将导致新文件无法被创建,尽管此时实际的存储空间还远远不到极限,所以在创建此类文件系统的时候需要考虑到这一点.

inode数计算公式:
inode_number=文件系统大小/nbpi

nbpi:The number of bytes per inode,每个inode所占用的字节数,它是文件系统inode数多少的决定因素.

在创建文件系统时,如果不特别指定,Solaris将根据文件系统的大小使用不同的nbpi值来决定inode的密度,参见下表.

文件系统大小(GB) 缺省的nbpi大小(byte)
≤1 2048
123≥1024(即1T) 1048576 (即1M)

根据上表,在默认情况下,对于一个1G的文件系统(在Solaris 9下,其可用的空间大约为961M),得到理论上的该文件系统所拥有的inode数:
1024 * 1024 / 2 ≌ 500000

而对于一个1T的文件系统,其可用的inode数将比略小于1T的文件(比如900G)系统锐减很多(因为nbpi值增大了好几倍):

900*1024*1024/8 = 117964800
1024*1024*1024/1024 ≌ 1000000 (一百万)

对于一个已创建的文件系统,可以通过下列命令得到该文件系统的可用inode数,从而得出在该文件系统下所能创建的最大文件数(不考虑实际的物理空间限制,理论值可能会与实际有些偏差,但可以作为一个参考):

# df -F ufs -oi

实验:
step1. 按缺省方式创建一个1G大小的UFS文件系统(nbpi=2048),挂接到/tmp/mnt目录下,实际可用的空间为961M:

# df -h /tmp/mnt
Filesystem size used avail capacity Mounted on
/dev/vx/dsk/oradg/lv_simon
961M 1.0M 903M 1% /tmp/mnt
# mkfs -m /dev/vx/dsk/oradg/lv_simon
mkfs -F ufs
-o nsect=64,ntrack=32,bsize=8192,fragsize=1024,cgsize=32,free=6,rps=120,nbpi=2054,
opt=t,apc=0,gap=0,nrpos=8,maxcontig=128 /dev/vx/dsk/oradg/lv_simon 2097152

# df -oi /tmp/mnt
Filesystem iused ifree %iused Mounted on
/dev/vx/dsk/oradg/lv_simon
4 507900 0% /tmp/mnt

在不考虑实际物理空间限制的情况下,该文件系统所允许创建的最大常规文件数理论值为: 507900个.

step2. 在该文件系统内用如下脚本循环创建小文件(<1K),观察实际所创建的文件数.

# cd /tmp/mnt
# more script.sh
i=1
while true
do
touch ./$i
i=` expr $i + 1 `
echo "$i" > ./$i
done

./507901: cannot create

发现脚本在创建了507900(与理论值一致)个文件后因为inode数量不够(实际的物理空间并未用完)而中断,如下:

# df -h /tmp/mnt
Filesystem size used avail capacity Mounted on
/dev/vx/dsk/oradg/lv_simon
961M 505M 399M 56% /tmp/mnt
inode数为:
# df -oi /tmp/mnt
Filesystem iused ifree %iused Mounted on
/dev/vx/dsk/oradg/lv_simon
507904 0 100% /tmp/mnt

通过以上实验,当创建文件系统时,有以下几个建议:

- nbpi值对于inode数量的多少有决定性的作用,但此值并非越小越好,如果此值太小,将会导致inode表占用太多的空间,从而使用于数据存储的空间减少,一般情况下,使用系统的默认值.

- 对于超过1T的文件系统,由于inode密度较稀疏,无法容纳太多的小文件(如超过二百万个),如果实际应用产生小文件的机率和频率较高,建议不要创建大于1T的文件系统,将其拆分成更小的文件系统.

 

Solaris下创建大于1T的文件系统http://blog.sina.com.cn/s/blog_45d51ebc0100049p.html