| 一．inode size 定义 | |||||
6.inode参数是可以通过mkfs.ext3命令改变的：
mkfs.ext3 -i 2048 -b 8192 -f 1024 /dev/sdb2
-i 2048更改inode每2KB创建一个
-b 8192设置block size的大小为8kB
-f 1024设置fragments的大小为1KB
mkfs.ext3 –N 2939495 /dev/sdb2
–N 2939495更改inode count。
二．更改一个分区inode参数的完整操作过程：
1.卸载硬盘分区：
[root@localhost ~]# umount /dev/hda7
2.调整inode参数
[root@localhost ~]# mkfs.ext3 -i 1024 -b 8192 /dev/hda7
mke2fs 1.39 (29-May-2006)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
2048256 inodes, 512064 blocks
25603 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=525250560
63 block groups
8240 blocks per group, 8240 fragments per group
32512 inodes per group
Superblock backups stored on blocks:
8240, 24720, 41200, 57680, 74160, 206000, 222480, 403760
Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 30 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.
3.修改/etc/fstab
修改前
[root@localhost ~]# vi /etc/fstab
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
LABEL=/opt /opt ext3 defaults 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
LABEL=/usr /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
LABEL=SWAP-hda8 swap swap defaults 0 0
~
修改后：
[root@localhost ~]# vi /etc/fstab
LABEL=/ / ext3 defaults 1 1
LABEL=/boot /boot ext3 defaults 1 2
devpts /dev/pts devpts gid=5,mode=620 0 0
tmpfs /dev/shm tmpfs defaults 0 0
/dev/hda7 /opt ext3 defaults 1 2
proc /proc proc defaults 0 0
sysfs /sys sysfs defaults 0 0
LABEL=/usr /usr ext3 defaults 1 2
LABEL=/var /var ext3 defaults 1 2
LABEL=SWAP-hda8 swap swap defaults 0 0
4.挂载分区
mount -a
5.完成后
参数-i 最小值是1024，这个值的大小决定inode count的大小，对应关系：
i=2048 Inode count:1025024
i=1024 Inode count:2048256
inode size的值在这是没有变化的，这也可以证明我上面定义的inode size。
让我们更加清晰的这几个定义之间的关系。
Inode size
Block size
Inode conut
[root@localhost ~]# dumpe2fs -h /dev/hda7
dumpe2fs 1.39 (29-May-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 440696ad-80e7-4810-8648-a9efda177ea9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal resize_inode dir_index filetype needs_recovery sparse_super
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 2048256
Block count: 1024128
Reserved block count: 51206
Free blocks: 873767
Free inodes: 2048245
First block: 0
Block size: 2048
Fragment size: 2048
Reserved GDT blocks: 512
Blocks per group: 8176
Fragments per group: 8176
Inodes per group: 16256
Inode blocks per group: 1016
Filesystem created: Fri Jul 11 18:10:33 2008
Last mount time: Fri Jul 11 18:11:02 2008
Last write time: Fri Jul 11 18:11:02 2008
Mount count: 1
Maximum mount count: 34
Last checked: Fri Jul 11 18:10:33 2008
Check interval: 15552000 (6 months)
Next check after: Wed Jan 7 18:10:33 2009
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal inode: 8
Default directory hash: tea
Directory Hash Seed: ad1b7c40-6978-49e9-82f6-2331c5cac122
Journal backup: inode blocks
Journal size: 32M
注释：由于时间关系：
关于mkfs.ext3 -i 2048 -b 8192 -f 1024 /dev/sdb2
中这个-i参数的定义，我是根据对应关系推断，给了它只是个逻辑概念的定义。
欢迎大虾们有更有力的论据来解释一下，或推翻我的观点。
三．读取一个树状目录下的文件/etc/crontab 的流程
<!--[if !supportLists]-->1. 操作系统根据根目录( / )的相关资料可取得 /etc 这个目录所在的 inode ，并前往读取 /etc 这个目录的所有相关属性；<!--[endif]-->
<!--[if !supportLists]-->2. 根据 /etc 的 inode 的资料，可以取得 /etc 这个目录底下所有文件的关连数据是放置在哪一个 Block当中，并前往该 block 读取文件的关连性容；<!--[endif]-->
<!--[if !supportLists]-->3. 由上个步骤的 Block 当中，可以知道 crontab 这个文件的 inode 所在地，并前往该 inode ；<!--[endif]-->
<!--[if !supportLists]-->4. 由上个步骤的 inode 当中，可以取得 crontab 这个文件的所有属性，并且可前往由 inode 所指向的Block 区域，顺利的取得 crontab 的文件内容<!--[endif]-->
<!--[if !vml]-->
<!--[endif]--> 四.硬链接 Hard Link 只是在某个目录下新增一个该档案的关连数据而已！ 1.举个例子来说，我的 /home/vbird/crontab 为一个 hard link 的档案，他连结到 /etc/crontab 这个档案，也就是说，其实/home/vbird/crontab 与 /etc/crontab 是同一个档案，只是有两个目录( /etc 与 /home/vbird )记录了 crontab 这个档案的关连数据罢了！也就是说，我由 /etc 的 Block 所记录的关连数据可知道 crontab 的 inode 放置在 A 处，而由 /home/vbird 这个目录下的关连数据,contab 同样也指到 A 处的 inode ！所以， crontab 这个档案的 inode 与 block 都没有改变，有的只是有两个目录记录了关连数据. 2.使用 hard link 设定连结文件时，磁盘的空间与 inode 的数目都不会改变！由上面的说明来看，我们可以知道， hard link只是在某个目录下的 block 多写入一个关连数据，所以当然不会用掉 inode 与磁盘空间。 3.当我们修改其中一个文件的内容时，互为硬链接的文件的内容也会跟着变化。如果我们删除互为硬链接关系的某个文件时，其它的文件并不受影响. 4.由于 hard link 是在同一个 partition 上面进行数据关连的建立，所以 hard link 是有限制的： a. 不能跨 Filesystem. b. 不能 link 目录。 五．软链接 1.软链接也叫符号链接，他和硬链接有所不同，软链接文件只是其源文件的一个标记。当我们删除了源文件后，链接文件不能独立存在，虽然仍保留文件名， 但我们却不能查看软链接文件的内容了. 2.Symbolic Link 与 Windows 的快捷方式可以给他划上等号，由 Symbolic link 所建立的档案为一个独立的新的档案，所以会占用掉 inode 与 block 3.所以可用使用软链接解决某个分区inode conut不足的问题(软链接到另一个inode count足够多的分区)
inode size 倒底要多大才比较好？有人说如果小档案多，则以 1024 byte 较好。
这样的思考原则好像不是很谨慎。多少才叫『多』呢？我想我们需要一点定量的分析才对。
首先我们来『观察』一下 inode size 大小对我们 filesystem (以下 filesystem 均简称 fs) 及系统的相对性影响:
inode size 越小，inode table 越肥，可用空间越小。
inode size 越小，link 就越长，越会拖慢速度。
inode size 越小，空间利用率就越高。
此外，因为 x86 的 pagesize=4K 的特性，在做 mmap() 及 swap 这类的 virtual memory 动作时，如果 inode size 为 4K 的倍数，将较有效率。
所以，看来 inode size <4K 除了空间利用率较高以外，其馀全都是缺点。
而就一般实际经验来讲，空间利用率的提高，并不足以弥补因 inode table 的肥大而浪费掉的空间......所以一般而言 4K 是一个不错的经验值。
上面最後一点，我们提到了『空间利用率的提高，并不足以弥补因 inode table 的肥大而浪费掉的空间』一个事实；它的确是一个事实，除非您的 fs 是专供 BBS 这种系统而使用。以下是一些参考数据:
表一: inode size 和 inode table 大小关系 inode size(byte) inode table 在该 fs 上所占掉的百分比
1024 12.57% (约 1/8)
2048 6.31% (约 1/4)
4096 3.19%
8192 1.63%
16384 0.84%
32768 0.45%
所以以一个 1GB 的 partition 来造 fs 为例，不同的 inode size 将会立刻 先使用掉的容量 (拿去存 inode table 了) 是:
表二: inode size 与 inode table 大小 (在 1GB fs 中) inode size(byte) inode table 大小
1024 128.7MB
2048 64.6MB
4096 32.6MB
馀类推
试想，一个 1GB 的 fs 就只为了 inode size=1024 而就先用掉了 128MB 的空间， 除非将来我们的小档案真的很多很多，不然是补不回来的。
再来我们举例比较一下 inode size=1024 与 inode size=2048 的 fs:
以一个大小不到 1k 的档存在 inode size=1024 的 fs 中，是比在 inode size=2048 的 fs 中省下了 1k 的空间；但在 1GB 的 fs □， 要有 (128.7-64.6) * 1024 = 65614 个这样多的小档案，才算是『赚到了』； 呵呵.....你的 fs □凑得出这麽多小於 1k 的档吗？
类推 512MB 的 fs □，就要有 32820 个小於 1k 的档才算『赚到了』。
小於 1k 的档，除非你是开 bbs 的，不然在同一个 file system 上 想凑出 10000 个都很难；
我想，不再举个更实际的例子，恐怕还是有人不信。 以下是我以前对某个 1GB fs 中的 file size 统计:
表三: 本人某个旧 1GB fs 中的 file size 统计: 档案大小的□围 该大小□围内的档案个数
不到1K的 6538
1-2K 2053
2-4K 1565
4-8K 1064
8-16K 1011
16-32K 595
32K以上 1112
OK，看起来很明显地，不满 1k 大小的档案个数，已经占了快一半了； 所以直觉上会认为 inode size=1024 比较好？错了......
以下是以 inode size 来看 (fs 为 1GB 大小) 相对浪费空间的大小:
表四: 档案空间相对浪费大小与 inode size 对应表: inode size(byte) 档案空间相对浪费大小加上 inode table 大小
1024 131766KB (即 inode table 大小)
2048 72743KB (inode table size + 1K*6538)
4096 57208KB (inode table size + 3K*6538 + 2K*2053)
8192 81410KB (inode table size + 7K*6538 + 6K*2053.....)
16384 162959KB (馀请类推)
32768 354549KB
所以反而以 inode size=4k 最佳。
上面那些『空间相对浪费大小』计算上有点复杂, 不另说明. (呵呵, 搞不好我的算法是错的......所以不敢公布算法)
以同样的分析来看我的 bbs 的情况, inode size=1024 是最佳的, 因为小於 1k 的档案竟然多达四万个以上.
/usr 分析出来是以 inode size=2048 最佳。
但请注意, 以上只是空间利用率的分析, 不是速度上的分析...