デフォルトのパッケージは古いCPUでも動くようにコンパイルされるからgccが対応しても意味がない可能性が。
64bit版ならSSEが使用されるはずではあるのだけれど。
自前でコンパイルするか最適化された物をどこかから持ってくるかしてみたほうが良いと思う。

aufs2どうだろ。
痛い信者が憑いてるみたいだし。

実装に作者や信者の人格が現れるわけじゃなし、ほっとけ。

>>514
実装に作者と信者の人格があわられるよ
reiserfsなんてマジ基地レベルの実装だっただろ
本人も犯罪者でマジ基地レベルだったし

開発者が痛いプロジェクトはどこも
実装も痛い

日本だとRubyとかSeesaa なんか狂信者の集まりだろ
実装もやばやばだし

>>516
その論理でいくと一番狂ってるのはJavaだな
実装も信者も

reiserfsのコードは、Linuxの一部としてみたら
異常だったかも知れないが、別に普通だろ。
神経質なところが基地外じみているが。

なんつうか、ディスカッションになってないね。aufs2。

攻めるべき相手も分かってないみたいだし、
解決すべき問題点も挙げているわけでもないし。

取り巻きからupstreamにマージしてくれよって言われて、
とりあえずこんなんあるんだけどどうよ、って流れでは
１００年経っても無理だね。

TOMOYOがどう攻めたか、誰を見方につけたか、くらいは学習すればいいのに。

TOMOYOもあまりいい例じゃないと思うが…

まあ興味を持ってくれる人が出てくるのを待つしかないからねえ。
FSなら変にもめなきゃ簡単に入りそうな気はする。

FS周りは保守的な人が多いから
むしろ入りにくいんじゃない？

（保守の面も含めて）安心して使えるのが未だにext3と
linuxはFS周りは遅れ気味で、だからこそbtrfsが注目されていると思う。

VFSに手を出さなければ他のFSが巻き込まれることはないので、
強硬に反対する人はまずいない。

カーネル見つかったよ！！
http://www.daily.co.jp/newsflash/2009/03/10/0001747074.shtml

>>525
windowsならシステムコールをフックするという方法があります。
フックした排他オブジェクトのロック関数内などで、これが呼ばれた場所と
スレッドＩＤを記録していけば、原因の特定が可能。
多分linuxにも応用できると思います。

>>530
なれない。HugeTLBが聞いてくるのは、それを使う前がTLBミスで性能劣化が起きているときだから、
数十、数百ギガとかのデータがないと、目に見える差は出ない。

>>531
4Gぐらいじゃ不幸になる？

>>532
http://www.oracle.co.jp/2shin/ora81/18_19.html

>>533
うそを教えるのはいくない

ウィルスに一票

うむ。httpあたりから、カーネルの脆弱性を突くペイロードを
送り込まれたといったところか。

まず、ageてしまって申し訳ないです。

>>543-544
となると、対策としては
カーネルのバージョンアップ（ディストリビューション自体も？）
Apacheのバージョンアップ
ぐらいしか無いということなんでしょうかね・・・

今回の攻撃では単に止まっただけであればいいのですが、
何か仕込まれてないか確認しないとまずいでしょうね。

SonicWall等のFWでそういう攻撃防げるのであれば、
導入することも検討してみます。

Fedoraの3年前のバージョンなんてとっくにサポート切れてるんだから
何されててもおかしくないぞ

>>542
invalid operand というのはコードがおかしな命令だったことを意味する。
バグでデータを壊すことはよくあるが、コードを壊すのはまず考えられない。
なので、可能性があるとしたら、メモリが化けた、CPUキャッシュが化けたっていうハード故障系か、
>>543 がいうように、ウィルスにやられた。だと思う

>>546-548
ハードの障害の可能性も考えると、
サーバーマシンごとそっくり新しいものにしたほうが安心ですよね。
とりあえずカーネルのバージョン上げて様子見ますが、
早いうちに置き換えられるよう検討します。

>>547-548
BUG macroで例外起こすために不当命令使ってる。

なので、そこだけで壊れているとは判断できない。