unoh.github.com

こんにちは、佐藤です。kernel 2.6系のext3からdir_indexというものがサポートされたようなのでどのような状況でパフォーマンスが向上するか実験してみました。

環境は以下です。

uname -a; cat /etc/issue.net
Linux 2.6.18-8.1.3.el5 #1 SMP Mon Apr 30 19:55:44 EDT 2007 i686 i686 i386 GNU/Linux
CentOS release 5 (Final)

まず/dev/sdb1にext3領域をを作ってみます。

sudo mkfs.ext3 -j /dev/sdb1
sudo tune2fs -l /dev/sdb1  # 詳細表示
....
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
....

dir_indexという項目があるので、このバージョンでのmkfs.ext3はデフォルトでdir_indexが適応されるようです。

比較のためにdir_indexが無い領域も作成します。

sudo mkfs.ext3 -j -O none /dev/sdb2
sudo tune2fs -l /dev/sdb2
...
Filesystem features:      has_journal needs_recovery
...

適当な場所にマウントします

 sudo mount /dev/sda /home/unoh/sdb1
 sudo mount /dev/sda /home/unoh/sdb2

テストのため計測プログラムを書きました。

g++ -o disktest disktest.cpp
./disktest 
-c N: create files
-a N: random access files
-d N: delete files
オプション -c で N個のファイルを作成します
オプション -a でN個のファイルの中からランダムに 2000個アクセスします
オプション -d でN個のファイルを削除します
操作はすべてカレントディレクトリに対して行います。

結果に影響ができないようにテストの度に以下のコマンドで ページ,dentry,i-nodeキャッシュを解放します。

sudo sysctl -w vm.drop_caches=3; sudo sysctl -w vm.drop_caches=0;

結果

ファイル作成

ファイルアクセス

ということで、ファイルの作成についてはdir_indexが無い場合ファイル数が増えるにつれて指数的にアクセスが遅くなっているのがわかります。

dir_indexがある場合は、ファイル数が増えても時間は比例的に増えます。

ファイルのアクセスについても同じような結果になっています。

これを見る限り dir_indexは非常に有効そうです。

ちなみに、bonnie++ というソフトウェアでも同じようなテストができるようです。