![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
・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 ファイルシステムの常識が通用しなくなっているみたいだなぁ。。
