[[diary/Kojima]]

・ext4 fsの振るまい

元はメンテナ MLに投げたネタだけど、日記のネタもないので転載(苦笑

ext4-dev なパッチをあてた mke2fs で -j オプションを指定して作ったパーティションが、サイズによって振舞いが違いそうだ、という話。

VMware上の2GBのパーティションをdumpe2fsしてみると、

 Filesystem volume name:   <none>
 Last mounted on:          <not available> 
 Filesystem UUID:          b82d572a-638d-4453-8f20-ab9345c622be
 Filesystem magic number:  0xEF53
 Filesystem revision #:    1 (dynamic)
 Filesystem features:      has_journal filetype needs_recovery sparse_super
 Default mount options:    (none)
 Filesystem state:         clean

となるのに対し、4GBのパーティションだと、

 Filesystem volume name:   <none>
 Last mounted on:          <not available>
 Filesystem UUID:          4f28bba5-effd-4383-bd72-fcd49293fc5a
 Filesystem magic number:  0xEF53
 Filesystem revision #:    1 (dynamic)
 Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
 Default mount options:    (none)
 Filesystem state:         clean

みたいに Filesystem features に機能が増えている。

そのせいか、4GBパーティションの場合 ls の -f オプション(ファイルシステム上のファイルやディレクトリをソートせずに表示する)
で ./ と ../ が最初にくることが仮定できないらしい。

 kojima@vmathlon[~/Xap]% ls -f /mnt
 Sources/  ./  ../  X/  lost+found/
 
 kojima@vmathlon[~/Xap]% ls -f  /mnt/Sources//
 PlamoBuild64.MesaLib-6.5.2  Mesa-6.5.2-plamo64.patch     mytest.tgz                MYDIR/
 Xap/                        ./                           Mesa-6.5.2-x86_64-P1.tgz  TmpPkg/
 MesaDemos-6.5.2.tar.bz2     ../                          Mesa-6.5.2/               TMP/
 7.1/                        testpkg.tgz                  memo.txt                  MYDIRhogehage/
 Mesa-6.5.2.plamo64/         PlamoBuild64.MesaLib-6.5.2~  MesaGLUT-6.5.2.tar.bz2    test.tgz
 TmpDir/                     MesaLib-6.5.2.tar.bz2        PKG/

2GBのパーティションの場合、ls -f は

 kojima@vmathlon[~/Xap]% ls -f ~/build/
 ./      configure.ac  Makefile.in   config.guess*  install-sh*  libdrm/       Makefile        libdrm.pc
 ../     aclocal.m4    libdrm.pc.in  config.sub*    ltmain.sh    shared-core/  libtool*
 README  Makefile.am   configure*    depcomp*       missing*     config.log    config.status*

のように ./ と ../ が最初に来る。

ファイルシステムの内部構造まで調べたわけではないけど、どうも dir_index あたりの機能で高速化のためにディレクトリエントリが
B tree的にハッシュされてるような印象。

ext2/ext3ファイルシステムは i-node ベースのファイルシステムの典型例だと思っていたけど、ext4 あたりになるとさまざまな工夫が
加えられて古典的な i-node ファイルシステムの常識が通用しなくなっているみたいだなぁ。。
-以前VMwareでLinuxを使用してIO関連が遅いため現在は各自Windows用とLinux用を専用に使用しています。最近のVMwareはext3などでLinux専用と比較してどの程度なのだろうか。 -- [[尾形]] &new{2007-01-25 (木) 12:11:37};

#comment

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS