inode简介与设置

关于inode的简介
来  源: freebsd.csie.nctu.edu.tw 
档  名: 0/System/inode(使用 70 埠) 
标  题: 关于 inode                       - About inode 
 
 
From: unixer.bbs@bbs.ee.ncku.edu.tw (优客李林) 
Newsgroups: tw.bbs.comp.386bsd 
Subject: 有关 inode... 
Date: 9 Dec 1996 08:27:00 GMT 
 
Hi... 
 
由于做过一些有关 filesystem 的 study, 在这边对 inode 做一点说明... 
 
1. inode 是作甚么的? 
 
  一个 filesystem 可以粗略地分成 inode table 与 data area 两部份. 
  inode table 上有许多的 inode, 每个 inode 分别 记录一个档案的属性, 
  与这个档案分布在哪些 datablock 上 
 
2. 一个 inode 有多大呢? 
 
  128 byte! 
 
3. inode 和 data area 的关系 
 
  在 new filesystem 时, 通常会有一个参数, 用来描述要分配多少比例的空间给 
  inode table. 举例来说, 
 
  newfs -i 2048 
 
  是指 file system 中, 每分配 2048 byte 给 data area, 就分配一个 inode 
  但是一个 inode 就并不是一定就用掉 2048 byte, 也不是说 files allocation 
  的最小单位是 2048 byte, 它仅仅只是代表 filesystem 中 
  inode table/data area 分配空间的比例是 128/2048 也就是 1/16 
  (换个角度想, 我们可以想成是预估 filesystem 中 file 平均大小是 2048 byte) 
 
  如果 inode table 太小, 那么在每个档案都很小的时候, 就会发生 inode 用光 而 
  datablock 还剩一堆的情形. 
 
4. file allocation 的最小单位 和 inode 多少有没有关系呢? 
 
  没有关系! 
 
  FFS 中真正的最小单位是 fragment size 也就是我们在 new filesystem 时用的 
 
  newfs -b 8192 -f 1024 
                ^^^^^^^^ 
  ps: -b 8192 代表 blocksize=8192, 这种"较大单位"是用来加速大档案的存取用的 
 
在 FreeBSD 中, 内定的是 -i 4096 -b 8192 -f 1024. 如果您要架 bbs/new 的话 
可以考虑用 -i 1024 -b4096 -f1024 
 
unixer 
 
============================================================================ 
From: alexj@mail.tmc.edu.tw (Ji, Wen-Jie) 
Newsgroups: tw.bbs.comp.386bsd 
Subject: Re: HELP !! The parameter of newfs 
Date: Thu, 12 Dec 1996 01:39:31 GMT 
 
        没关系,我自己找到答案了,写在此让大家分享一下. 
        所谓 block size & fragment size, 这是属于 file system 
        的一种解决方案. 自4.3 BSD, BSD 用这种方法来解决档案 fragment 
        的问题 
                先假设  a block size= 4K, a fragment size = 256Bytes. 
        假如你现在要将一个 1K 的新档案写入 file system, FS 会把它存入 4 
        个fragment,而不会存入 block,一但这个档案继续被 append 增加到 4K 
        时, FS 会将它转存到一个 block中, 而原来的 16 个fragments 就会被 clean 
                                           ^^^^^^^^^^^^^^^^^^^^ 
                                       因为当你的档案大到 4K 时,它占用 
                                       了 16 (4K / 256 bytes) 个 fragments 
                再举个例子, 如果现在又存了一个新的 4.1K 的档案, FS 会分配 
        一个 block 及 4个 fragment 给 这个档案, 
        因为 1 block + 4 fragments = 4 K + 256 bytes * 4 = 4.1K 
 
        所以,有此可知,对于一台 news server, bbs, 或是会有大量的小档案存取时, 
        为了降低 FS 的空间耗损率,应该采用 -b 4096 -f 256, 
        而不要采用预设值的 -b 8192 -f 1024,因为大部分的信件都不超过 512 bytes, 
        有些更不超过 256 bytes, 但是这样可能会降低存取的速度.但我相信不严重 
        有兴趣的人可以试试. 
 
========================================================================= 
 
        newfs 时的参数的影响：(以 100MB 的分割去作测试) 
 
＞From jason@csie.NCTU.edu.tw  Fri Mar 14 23:53:58 1997 
From: Jason Chang 
inode大小的最佳设置

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 最佳。

但请注意, 以上只是空间利用率的分析, 不是速度上的分析....