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 大小关系
所以以一个 1GB 的 partition 来造 fs 为例，不同的 inode size 将会立刻 先使用掉的容量 (拿去存 inode table 了) 是:
表二: inode size 与 inode table 大小 (在 1GB fs 中)
试想，一个 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 统计:
OK，看起来很明显地，不满 1k 大小的档案个数，已经占了快一半了； 所以直觉上会认为 inode size=1024 比较好？错了......
以下是以 inode size 来看 (fs 为 1GB 大小) 相对浪费空间的大小:
表四: 档案空间相对浪费大小与 inode size 对应表:
所以反而以 inode size=4k 最佳。
上面那些『空间相对浪费大小』计算上有点复杂, 不另说明. (呵呵, 搞不好我的算法是错的......所以不敢公布算法)
以同样的分析来看我的 bbs 的情况, inode size=1024 是最佳的, 因为小於 1k 的档案竟然多达四万个以上.
/usr 分析出来是以 inode size=2048 最佳
