和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[/i]可以的话，应该有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大于这个平衡值，那就得有足够的耐心等待性能。。
|
|
