ext3固定分区后可以设置inode的数量最大为多少？

 原贴:http://blog.chinaunix.net/u/6303/showart_531007.html

ext3固定分区后可以设置inode的数量最大为多少？ 和mlsx约定好了，每人写一篇，最后会合，本来我是想查查资料后，想想，然后就等待他的结果了。 但似乎他有点瞧不上不喜欢动手的人（属于臆断），那么我就只好硬着头皮上了，其实最可能的原因 就是我本地没有多余的磁盘，呵呵，那我也只能使用loopsetup了。 废话就不多说了，代码多读，多交流，互相印证才是此文的最终目的！ Ext3 文件系统将其所管理的磁盘或者分区(引导块除外)中的块划分到不同的块组中。每个块组大小 相同，当然最后一个块组所管理的块可能会少一些，其大小在文件系统创建时决定，主要取决于文件 系统的块大小，对于大小为4k的文件系统块来说，块组大小为 168M。每个块组都包含一些重要的元 数据信息，见下图： 或是如下图： 每个块组包含一个块位图块，一个 inode 位图块，一个或多个块用于描述 inode 表和用于存储文件数据的 数据块，除此之外，还有可能包含超级块和所有块组描述符表(取决于块组号和文件系统创建时使用的参数)。 下面将对这些元数据作一些简要介绍。 块位图用于描述该块组所管理的块的分配状态。如果某个块对应的位未置位，那么代表该块未分配，可以用于 存储数据；否则，代表该块已经用于存储数据或者该块不能够使用(譬如该块物理上不存在)。由于块位图仅占 一个块，因此这也就决定了块组的大小。 Inode位图用于描述该块组所管理的inode的分配状态。我们知道inode是用于描述文件的元数据，每个 node对应文件系统中唯一的一个号，如果inode位图中相应位置位，那么代表该inode已经分配出去；否则 可以使用。由于其仅占用一个块，因此这也限制了一个块组中所能够使用的最大 inode数量。 Inode表用于存储inode信息。它占用一个或多个块(为了有效的利用空间，多个inode存储在一个块中)，其 大小取决于文件系统创建时的参数，由于inode位图的限制，决定了其最大所占用的空间。 超级块用于存储文件系统全局的配置参数(譬如：块大小，总的块数和inode数)和动态信息(譬如：当前空闲 块数和inode数)，其处于文件系统开始位置的1k处，所占大小为1k。 上述资料来源于http://www.ibm.com/developerworks/cn/linux/l-cn-ext4resize/index.html，感谢作者！ 理论部分说的差不多了，再深了就去/usr/src/$kernel/fs/ext3.c里看吧。现在我们就拿实际数据来验证一下吧。 具体的实验环境请参考本人以前写的一篇文章：http://blog.chinaunix.net/u/6303/showart_499626.html 环境：ubuntu8.04-alpha6 + ext3  + dumpe2fs1.40.8 建立一零文件，大小大约为500M [root@lee-laptop LVM-test]# dd if=/dev/zero of=./file3.img bs=1000k count=512 512+0 records in 512+0 records out 检验结果 [root@lee-laptop LVM-test]# du -s file3.img 512504    file3.img 建立loop设备 lee@lee-laptop:/media/sda6/LVM-test$ sudo losetup /dev/loop0 file3.img 按照默认值格式化： lee@lee-laptop:/media/sda6/LVM-test$ sudo mkfs.ext3 /dev/loop0 mke2fs 1.40.8 (13-Mar-2008) Filesystem label= OS type: Linux Block size=1024 (log=0)                          Fragment size=1024 (log=0) 128016 inodes, 512000 blocks 25600 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 63 block groups 8192 blocks per group, 8192 fragments per group 2032 inodes per group Superblock backups stored on blocks:     8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 Writing inode tables: done                            Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 26 mounts or 180 days, whichever comes first.  Use tune2fs -c or -i to override. 分析： 块大小默认为1024个字节，共有512000个块，则依据公式:分区中的块组数＝分区大小/(块大小*8) 512504/1024*8=63（此处的1024为data-block-bitmap大小）,也就说块组为63没错。 我们再来看inode. inode-bitmap占一个块大小，也就说有1024byte，则每个块组中可至多存在inode数为1024*8即8192 个inode,因为1byte=8bit。 那么每个块组中存有8192个inode应是一个极限的值，当block大小决定了，那么这个分区的块组 也相应的被决定了，现在算下假如上述情况下，这个512504大小的分区，最多能指定inode数是多少？ 8192*63=516096个 下面开始验证这么一个“阀值”？ lee@lee-laptop:~$ sudo mkfs.ext3 -b 1024 -g 8192 -N 516097 /dev/loop0 mke2fs 1.40.8 (13-Mar-2008) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 516608 inodes, 512000 blocks   //此处的inode已经不是我们指定的了，比我们预料中的多出511个。 25600 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=66906624 64 block groups                         //组也不是我们预料中的63了。 8104 blocks per group, 8104 fragments per group   //组已经不是我们设定的8192了 8072 inodes per group Superblock backups stored on blocks:     8105, 24313, 40521, 56729, 72937, 202601, 218809, 397097 下面是正常的情形。 lee@lee-laptop:~$ sudo mkfs.ext3 -b 1024 -g 8192 -N 516096 /dev/loop0 mke2fs 1.40.8 (13-Mar-2008) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 516096 inodes, 512000 blocks 25600 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 63 block groups 8192 blocks per group, 8192 fragments per group 8192 inodes per group Superblock backups stored on blocks:     8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 lee@lee-laptop:~$ sudo mkfs.ext3 -b 1024 -g 8192 -N 516095 /dev/loop0 mke2fs 1.40.8 (13-Mar-2008) Filesystem label= OS type: Linux Block size=1024 (log=0) Fragment size=1024 (log=0) 516096 inodes, 512000 blocks 25600 blocks (5.00%) reserved for the super user First data block=1 Maximum filesystem blocks=67633152 63 block groups 8192 blocks per group, 8192 fragments per group 8192 inodes per group Superblock backups stored on blocks:     8193, 24577, 40961, 57345, 73729, 204801, 221185, 401409 虽然上述验证了理论，但是新的问题又出来了，当我们给定的三个参数中，有矛盾之处，那么系统 会优先满足谁了呢？ 答案是显而易见的，满足了指定的inode数，但是块组中包含的块数却发生了变化！ 由此可以看出，系统挪用了其他一些资源来满足这个特定的要求，但已是不能到具体了。那么这个极限值又是多少了呢？ 经过几次反复试验，发现系统是减少了块组中的块数，也就是说让系统多出个块组了，来满足inode的数量。 那么当块组为64的时候，最大的inode数应该为524288,每组的块数为8104。 块组为65的时候，最大的inode数应该为532480，每组的块数为7976。 块组为66的时候，最大的inode数应该为540672，每组的块数为7856 ...... ...... 当每组的块数为1296 的时候，则系统共有395个块组，则如果 inode可以的话，应该有3235840个，这是最后的极值。 那么能否总结出什么规律了呢？再来查看下此时的dumpe2fs的输出： Filesystem volume name:   <none> Last mounted on:          <not available> Filesystem UUID:          a3d9f790-b10f-4069-b370-b1272adbd261 Filesystem magic number:  0xEF53 Filesystem revision #:    1 (dynamic) Filesystem features:      has_journal ext_attr resize_inode dir_index filetype sparse_super Filesystem flags:         signed_directory_hash Default mount options:    (none) Filesystem state:         clean Errors behavior:          Continue Filesystem OS type:       Linux Inode count:              3235840 Block count:              511921 Reserved block count:     25600 Free blocks:              94900 Free inodes:              3235829 First block:              1 Block size:               1024 Fragment size:            1024 Reserved GDT blocks:      256 Blocks per group:         1296 Fragments per group:      1296 Inodes per group:         8192 Inode blocks per group:   1024 Filesystem created:       Mon Apr 14 15:38:09 2008 Last mount time:          n/a Last write time:          Mon Apr 14 15:39:07 2008 Mount count:              0 Maximum mount count:      27 Last checked:             Mon Apr 14 15:38:09 2008 Check interval:           15552000 (6 months) Next check after:         Sat Oct 11 15:38:09 2008 Reserved blocks uid:      0 (user root) Reserved blocks gid:      0 (group root) First inode:              11 Inode size:               128 Journal inode:            8 也就说此时，在每个块组中除去inode占用的，只有272个块，除去4个固定的块，则有268个块，那么这就是剩下的data所占用的块了。 这个时候是没有意思的，虽然inode多了，但是能存储的数据却少了很多。 也就是说我现在这个500M的空间，只能存储268＊1024＊395＝～100M 没错，请看我的df输出结果。 /dev/loop0            104M   12M   68M  15% /media/sda6/LVM-test/test 所以，最后的总结仍然是取得一个平衡值，既不影响到数据块，又能使inode最大。 当然如果你非执拗的不行，非得设置inode大于这个平衡值，那就得有足够的耐心等待性能。。 发表于： 2008-04-14，修改于： 2008-04-14 16:21，已浏览292次，有评论1条 推荐 投诉

网友评论 网友： mlsx 时间：2008-04-15 08:49:17 IP地址：220.205.178.★ 1）果然是臆断 2）个人感觉没有必要在这个问题上钻入这么深，觉得了解了-i和-N就差不多了。 3）硬盘资源确实是稀缺资源，所以我一直都用iSCSI。