diary/Kojima/2007-01-23
の編集
http://sv5.linet.gr.jp/index.php?diary/Kojima/2007-01-23
[
トップ
] [
編集
|
差分
|
バックアップ
|
添付
|
リロード
] [
新規
|
一覧
|
検索
|
最終更新
|
ヘルプ
|
ログイン
]
-- 雛形とするページ --
diary/Template
[[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
タイムスタンプを変更しない
[[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
テキスト整形のルールを表示する