iノードの理解を深める
はじめに
Unixのファイルシステムに関してちょいちょい勉強してくよー。
という感じで今日はiノードについて。
参考資料はお馴染みの『Amazon.co.jp： 改訂 新Linux/UNIX入門: 林 晴比古: 本』とネットから。
iノードって？
iノードはindex-nodeの略で、
ファイルが作られるたびに、それに1対1対応するように作成される管理情報のことを指す。
管理情報というと難しそうに見えるが、よくお目にかかるファイルサイズや最終更新日などもこれに含まれる。
他には、リンク数、作成時間、所有者のユーザID,最終アクセス時間、ブロック番号などが含まれる
「ブロック番号」ってあまり馴染みがないけども、ディスク上でのファイル本体の格納場所の情報が入っているらしい。
いわゆる、CやC++でいうポインタ。
また、それぞれのiノードには、iナンバというユニークの識別番号が付与され、
ディレクトリは、このiナンバとファイル名をたくさん持っているもの、として考えることができる。
例えば"Hello World"と書かれたfile1.txtを、cat file1.txtとして出力する処理は以下のようになる。
- ディレクトリを見て、ファイル名(file1.txt)と対になるiナンバ(1000とする)を特定する
- iナンバ(1000)を用いて、iノードテーブルから該当するiノードを取り出す
- iノード中のブロック番号(3000とする)を見る
- ディスク領域でブロック番号(3000(が指す箇所を参照しにいく
- その箇所にあるファイルの実態を見つける→出力される
DBのテーブル的な感じで管理されていて、主キーのiノードから全部引っ張ってくる、といった印象を受けたけども実際そんな感じなのだろうか。
ブロック番号と関節指定ポインタ
iノードで指定できるブロック番号
上の例でfile1.txtが出てきたけど、これぐらいファイルサイズの小さいものなら1つのブロックに収まる。
ただ、動画や高解像度の画像となるとそうはいかないので、複数個のブロックを指定する必要がある。
Linuxのext3というファイルシステムは、iノードのブロック番号を12個指定できる。
一個のブロックの大きさは、1024byteか、2048byteか4096byteから指定できる。
UNIXの中には8192byteを指定できるものもあるらしいが、そうするとファイルサイズが小さい際に無駄な領域が多くなってしまって非効率。
例えば1つのブロックの大きさを1024byteとすると。
iノード中でそのブロックを指す番号を12個まで指定できるということは、1024byte✕12で約12Kbyte。
一昔前のフロッピーディスクに収まるぐらいでとても少ない。
それ以上のファイルサイズのものを持ってこようとすると、以下の関節指定ポインタを使う必要が出てくる。
関節指定ポインタ
端的に言うと、1つのブロック(X)に、他のブロック(Y)を指し示す4byteのポインタを256個入れれば巨大なファイルも扱える。
さらに、その他のブロック(Y)を指し示す先のブロック(Z)に4byteのポインタを256個入れれば…、といった感じ。
関節指定ポインタは、Linuxだと三重にまですることができ（四重とかもいける？）、
1ブロックの大きさが1024byteだと以下の表のようになる。
| 単一関節指定ポインタ | 256✕1024 | 256KB |
| 二重関節指定ポインタ | 256✕256✕1024 | 64MB |
| 三重関節指定ポインタ | 256✕256✕256✕1024 | 16GB |
関節指定することで、12KBまでしか扱えなかったのに16GBまでのファイルを格納することができるようになった。
仕組みはシンプルなだけに、なんかすげー。
おわりに
今回はiノードに関しての理解を深めるとこまで。
次は、iノードを絡めたシンボリックリンクとハードリンクについて書くよー。
疑問
Windowsだとファイルサイズが２GBか4GBぐらいまでしか扱えないのは、一つのブロックサイズが小さいからなのかな？
無駄が小さくなる代わりに巨大なファイルが扱えなくなるってのは、OSごとにどっちを優先するかに寄るのかも。
いや、でも1ブロックサイズを1024とすると、
64MB以上のファイルを扱う際に無駄なブロックがでてくるからどっちもどっちか。
でも無駄といっても、使われていないのなら他のために使われてるんだよなぁ。
100MBの動画で16GBディスク容量を食うってことになるし。
うーむ、もっと調べる必要がありそうだ。
