ext3のファイル削除が遅い。逆転の発想で解決。 | Tom's Lab
２０１１年３月４日（金）晴れ 今日も寒かった 以前にも書いたが、ext3は巨大ファイルの削除が遅い。WindowsのNTFSならあっという間に削除される。サーバOS(用途?)のLinuxがDISK I/O関係でWindowsに負けるなんて悔しいです。 それもDECのお下がりのNTFSに。。。 5GBのファイルを削除すると、私の環境では８秒かかる。BSの２時間ドラマのファイルであれば１６GBになり、３０秒近くかかる場合がある。おまけにファイル削除中は該当DISKへのアクセスが全て止まってしまう。ほんとシステム全体が止まった状態になる。 で、以前から対策ができなか調べていた。 最近、RegzaのHDDのファイルシステムがXFSであることが分かり、ext3からXFSにすれば削除が速いのでは？と思ったが、なんとネットで調べるとXFSは削除がext3より更に遅いらしい。 更に「ext3 削除 遅い」
ext3のジャーナル(lost found)再作成
Linuxのext3ファイルシステムにあるlost+foundはファイルシステムのジャーナルです。これのおかげでfsckがすぐに終わります。これを間違って消した場合やおかしくなった場合は以下のようにして再作成ができます。 まずはファイルシステムをチェック # umount /dev/sdc1 # e2fsck -fn /dev/sdc1 ext2にいったん戻して、ext3に変換。 # tune2fs -O^has_journal /dev/sdc1 # tune2fs -j /dev/sdc1
filesystem/ext3 - Linux Tips
hashed b-treeの使用 † hased b-treeを使用し、ファイルが多いディレクトリ内での検索(と言うか参照)を高速化する。ただし、kernel-2.6以降のみ対応。 ファイルシステム作成時に指定するか、 # mkfs.ext3 -j -O dir_index /dev/hdxx 既存の物に対しtune2fsの後、e2fsck -Dを行い、既存のディレクトリ インデックスをhashed b-treeに変換する。 # tune2fs -O dir_index /dev/hdxx # e2fsck -D /dev/hdxx ↑ journal log を別デバイスに置く † ext3を/dev/hdxx、journal logを置くデバイスを/dev/sdxx、journal log size(block数)をssssとすると、パーティションを新たに作成する場合は、 # mke2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
