Tweet
最近、小さなファイルを大量に作成するようなシステムに触れる機会があり、その際にiノード数不足がが云々という話になりました。
ext3の場合、iノードはフォーマット時に決める必要があります。
その際にiノード数を決定するのはブロックサイズです。
デフォルトではブロックサイズが4096(byte)で1024(byte)にすることでデフォルトの4倍のiノード数になります。
というか、このブロックサイズ、いったいどういう意味があって大きくしたり小さくしたりすることでどんな影響が出るのかわかってません。
なので調べてみました。
まず、ブロックサイズとは何か。
HDDなどのデバイスは「セクタ」という単位でデータが保存されます。
多くの場合、磁気ディスク(HDDなど)は1セクタ512バイト、光ディスクの場合2048バイトが主流です。
そのセクタをひとまとめにしたものを「ブロック」と呼びます。
そのブロックのサイズが「ブロックサイズ」です。
なので、セクタサイズ以下にブロックサイズを設定することはできない(はず)です。
つまり、1バイトのデータを保存したとしても、ファイルシステムで消費されるのは1ブロックです。
1ブロックを消費するということはどんなに小さなデータを保存してもデフォルトだと4096バイト消費されます。
この場合、4095バイト無駄になってしまいます。
逆にブロックサイズを1024バイトにした場合、その無駄は1023バイトまで小さくすることができます。
小さなファイル(ブロックサイズより小さいサイズのファイル)を大量に生成するようなシチュエーションの場合、ブロックサイズは小さくする方が良さそうです。
では、「ブロックサイズはセクタサイズと同じにすれば無駄なくディスクを消費できるのではないか?」と思いますが、ブロックサイズが小さいことによる弊害も発生します。
ブロックサイズが小さい場合、大きな容量のファイルを扱ったときに多くのブロックを必要とします。
この場合、ファイルアクセス時使用される「間接データブロック」という仕組みと関係します。
ext3ファイルシステムでは大きな容量のファイルを取り扱うために、間接データブロックという仕組みを利用しています。
データブロックを参照するためにファイルには15個の参照ポインタのようなものが存在します。
それらの12個は直接参照、1個は1段間接ブロック(間に1個のブロックをマッピングするためのテーブルを持つブロックがある)、1個は2段間接ブロック、1個は3段間接ブロックで構成されています。
ブロックサイズが小さいと多くのブロックを消費するために、このブロックポインタも多く必要になります。
そのため、間接参照を行う回数が増え、パフォーマンスの面で不利になります。
さらに、間接データブロックの仕組みを利用し、ブロックサイズ4096バイトでは2TBまでのファイルを扱うことができます。
しかし、これはブロックサイズが小さくなればその分扱うことができるファイルの容量も小さくなってしまいます。
計算では4分の１なので500GBぐらいかと思っていたのですが、下記のサイトを見ると16GBと記述されています。
ext3の最大ファイルサイズは2TBでなく16GB?!
ここまで書いてきましたがまとめるとこうなります。
- ブロックサイズより小さなファイルを大量に扱う場合はブロックサイズを小さくして、iノード数を増やした方が良い
- ブロックサイズを小さくするとファイルを扱うパフォーマンスが落ちる(特にサイズが大きなファイル)
- ブロックサイズを小さくすると1ファイルで扱える最大容量が小さくなる
ブロックサイズは適度なサイズにしましょうと言う話でした。
ちなみに、今稼働中のLinuxのブロックサイズはdumpe2fsコマンドの「Block size」で参照することができます。
参考
Tweet