HDDのエラーが発生したときにext3領域がReadOnlyになってしまう件。 以前から何度か経験してたけど、tune2fsの出力を見るとエラー時の動作は デフォルトでContinueになっている模様。 Errors behavior: Continue てっきり毎回ReadOnlyで再マウントされてたので、この点がremount-roになってる のかと思っていた。が、そうなってなかったので調べてみた。 ReadOnlyで再マウントする処理は以下の二箇所(2.6.9カーネルより抜粋) @fs/ext3/super.c:ext3_abort if (test_opt(sb, ERRORS_PANIC)) panic("EXT3-fs panic from previous error\n"); if (sb->s_flags & MS_RDONLY) return; printk(KERN_
じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。CPU は Athlon64 X2 4400+ ですが、まだまだ当分この CPU で間に合いそうです。HDD は当時は 7200 回転で最速だった HITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜本的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで
あまりCNET向きとは言えない技術的過ぎるTIPSで恐縮なのだが。 Linuxのドキュメントには次のように記載されている。 現行の単方向リンクのリストによるディレクトリの実装で、一つのディレクト リ内のファイル数は、実運用上約 10-15k 個が上限になります。この制限はこ のような大きなディレクトリ内のファイルを作成および削除 (さらに検索) す る時のパフォーマンスの問題のためです。 JF: Linux Kernel 2.4 Documentation: ext2.txt より 注:これは現在主流のext3ではなく古いext2のものだが、実際問題としてこの制限はほとんど変わっていない。xfsになると話は別だが。 ということで、ひとつのディレクトリにつくれるファイル数は1万個くらいにしておいたほうがいいようだ。 だが筆者の経験上ではせいぜい5000個くらいでやめておいたほうがいい。
By Justin Piszcz Introduction After the last article was published, I have received more than a dozen requests for a second filesystem benchmark using the 2.6 kernel. Since that time, I have converted entirely to XFS for every Linux machine I use, so I may be a bit bias regarding the XFS filesystem. I tried to keep the hardware roughly the same. Instead of a Western Digital 250GB and Promise ATA/1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く