難産のカーネル 26
ストーリー by wakatono
2.4系カーネル導入に影？ 部門より
2.4系カーネル導入に影？ 部門より
k3c 曰く、 "本家でも話題になったのですが、LinuxWorld.comに"Kernel of pain"という記事が出ています。内容は2.4.xカーネルを顧客のシステムに適用してからの艱難辛苦の日々…涙なくしては読めません。記事の最初に"Let's call a spade a spade"と書いてあるのもうなずけます。これだけの災厄に見舞われたら誰だって諦めるよねえ…。
/.Jのみなさんは2.4.xカーネルを使って、どんな災厄に見舞われましたか？"
オレも 2.4系カーネルを何箇所かで使っているが、今のところは災厄というほどの災厄に見舞われたことはない。しかし、実際に使用してる人の中には苦労したというのもあるのではないか。実際のところどうなんだろうか。
tcp_ecn... (スコア:3, 参考になる)
LKML を運営している VGER.KERNEL.ORG [kernel.org] にでっかく「TCP/ECN IS ON!」
と出ていて，強い意志が感じられます．ECN を有効にしないと
一部の netfilter 系のモジュールがコンパイルできなくて，有
効にしてたんですが…
「特定のサーバの Webが見られない」とか「メールが送れない」と
いう現象が出ていて原因不明で相手に問い合わせてしまいました．
リリースされているカーネルには「デフォルトで OFF にする」と
いうオプションがあるのでいいのですが，ふだん pre をつかっ
ているので，突然こうなったときは驚きました．
＃www.geocities.co.jp とか village.infoweb.ne.jp とかに
＃つながらなかった．
/etc/sysctl.conf に net/ipv4/tcp_ecn = 0 と書いて，sysctl -p
すると無効になります．
% cat /proc/sys/net/ipv4/tcp_ecn
0
ぼくにとってはこれが最大の災厄でした．
＃って LKML とかきちんとチェックしてればいいだけですね… ^^;
なんで2.4? (スコア:1)
Linuxでサーバを運用している人の話を聞くと, まだ怖いので2.2.xとかいうことが多いのですが, 今業務システムで2.4.xを使うとしたらどんな理由が有るのでしょうか?
ちょっと思いつくところでは
ぐらいなんですが, 業務システムは動いてなんぼですからね...
Re:なんで2.4? (スコア:1)
もっとも、そのつもりがファイルシステムボロボロで泣きを見たってパターンは最近まではありそうだったけど。ほんと2.4のリリース管理はちょっとヒドすぎた。Linusってリリース管理に向かないのな、と本気で思ったりしたもの。俺個人は一部仕事で使っていながらそこまでヒドい目には遭わなかったけど、それは運がよかっただけ。
# 仕事で一番大切かつ負荷のかかるサーバは、2.2.19+reiserfs3.5.24に個人的にいくつかパッチ当てたものを使ってて、岩のように安定している。
Re:なんで2.4? (スコア:1)
という理由もありえます。
Re:なんで2.4? (スコア:2, おもしろおかしい)
合わせるRedHat [softagency.co.jp]の哀れな実験台なのですね。
Re:なんで2.4? (スコア:1)
Re:なんで2.4? (スコア:0)
まだ自分のサーバで2.4.xを実験してないので、
仕事で使うサーバはまだ怖いので2.2.x使ってます。
さして2.2.xでも問題ないし、
安定している事が確認できるならそれでいいような。
かなり臆病者です。
クライアントサイドの話だが (スコア:1)
（quota が動かない、RAID がうまく動かない、… ）が、
正式リリース後の 2.4 カーネルでは問題らしい問題はなかったな。
クライアント用途としては、むしろ XFree86 4.0.0 がお亡くなりになったり、
Mozilla が実用に耐えなかったり(M16とかそのあたりの話で、最近はそうでもない)、
Nautilus が重すぎたり（これは今でも）、
GNOME のいくつかのアプリケーションがいつも不具合を起こしたり(GnomeCCが多い)、
とそういう方が問題だったな。
ちなみに 2.4 に乗り換えるきっかけは
RAID デバイスの新しいバージョンを入れてみるためだったように思われ。
# mishimaは本田透先生を熱烈に応援しています
脅さないでくださいよ(汗) (スコア:1)
Re:何でext3? (スコア:1, 参考になる)
しているのに、まだ実績のないext3を稼動中のサイトに採用する
とは、チャレンジャーですね。fsckする機会なんてほとんどない
でしょうから、別にext2で十分じゃないでしょうか。
ファイルサイズ制限を超える必要から、採用なさったんでしょうか。
Re:何でext3? (スコア:2, 参考になる)
もちろん、試験的なext3を使う程重要かリスクかどうかはケースバイケースで決めなきゃいけませんけどね。
Re:何でext3? (スコア:1)
>サーバーをfsckする機会は「ほとんどない」といっても、万が一落ちてしまった場合の復旧の速度は非常に重要です。
ext2ですと, 一定回数あるいは一定期間後のシステム立ち上げ時に強制的にfsckが走るんじゃありませんでしたっけ? いかにサーバとは言え, 電源系の定期メンテナンスのため年に1回ぐらいは止める運用が多いと思いますので, fsck無しで済むというのはやはり大きいですよね.
ところで最近の100GB超のディスクってfsckにどの程度の時間がかかるのでしょうね?
Re:何でext3? (スコア:1)
そんなあなたに man tune2fs(max-mount-counts)
Re:何でext3? (スコア:1)
-i 0 (interval-between-checks) もお忘れなく。
"Quidquid latine dictum sit, altum videtur."
Re:何でext3? (スコア:0)
そういう話じゃなくて，ext2では定期的なfsckは基本的に避けられない，ということかと．
Re:何でext3? (スコア:2, 参考になる)
最初はReiserFSだったんだけど、NFSとの相性や高負荷時に
激遅だったので、かなり早くからext3にした。それから幸せ。次のクラッシュ／ハードメンテに2.4になる一台を除き、全部2.4だが、こっちの方がパフォーマンスも安定度も上。SMPの性能は当然ながら、I/Oとかも良い感じ。もう2.2は使えないね。
Ingoの新しいO(1)スケジューラJ2版の2.4系バックポート
ないかなぁ。実験する暇ないけど。
Re:何でext3? (スコア:1)
逆パターンです (スコア:1)
また、つい先日、たまたま2GB超のファイルを保存しなければならなくなったのですが、そのときには2.4.xのありがたみを感じました。
反対に、2.4.xにしてから困ったことですが、これは、ディストリビューション付属のpppdを用いてPPP接続ができなくなったというあたりでしょうか。最新版のpppdをもってきたら解決しましたが。
あと、ReiserFSには何度か泣かされたクチですが、これは2.2.xからの付き合いなので、2.4.xの問題というわけではなく… むしろ2.4.10(だったかな？)以降、NFSとの相性も改善された(に見える)わけで。
というわけで、私の場合は、災厄よりも恩恵のほうが大きいのですが、実は珍しい事例なんでしょうか。
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:逆パターンです (スコア:1)
RedHat7.2Jを使っていることが問題の原因なの かもしれませんが、NFS Ver.3でマウントした ディレクトリのエントリのサイズが4096を 超えたあたりから、tcshなどがreaddir()に失敗 するという問題です。2.4.8ac12以前では、 この現象が発生しないので2.4.9以降を 使うのは控えています。
ちなみに、LFS関連の対処法(readdir64を 使うようにする)でこの問題に対処できる ことはわかったのですが、問題が発生する コマンド全てのリコンパイルが必要なので 今のところ放置しています。
普通に発生しそうな不具合なのに、うち以外 ではこの問題の話を聞いたことがないので、 もしかしたらサーバ側の問題なのかもしれ ませんが...
RedHatには、うちの担当者が報告したらしい のですが、何も反応無いそうです。
tt
LinuxWorld.comの記事は痛すぎ (スコア:0)
2.4でトラブルが出たら2.2に戻せばいいだけ。（Mandrake 8.0には2.2のパッケージがあるはず）
stableだからといって最新のカーネルを追いかけたりは普通しない。（だから、2.4.15を入れたのに、すぐにバグフィックスの2.4.16が出たりってことになる）
まるで (スコア:0)
カーネルが大きくなってくると、結局そうなるのでしょうか。
Re:まるで (スコア:3, 参考になる)
カーネルソース全体のサイズだけなら確かにそうかもしれない。しかし実際必要なモノはたかがしれてる。たいてい、
# make-kpkg --revision selfbuild.1.0 kernel-image (このコマンドあるからDebianはやめられへん)
とかやって、できたカーネルのサイズは2HDフロッピー1枚くらいのサイズになるし。
Re:まるで (スコア:2, おもしろおかしい)
「問題があったときにどう対処できるか」だと思いますよ。
そこで、両ユーザの違いを書いてみました。
if( OS==Windows ){
while(!isUpdated_WindowsUpdate()){
User.sleep(new Date(1));
}
win.doWindowsUpdate();
win.reboot();
win.doWindowsUpdateAgain();
win.rebootAgain();
try{
win.doWindowsUpdateAgain2();
win.rebootAgain2();
}catch(NormalBootException e){
System.out.println("Fortunately WindowsUpdated successfully.\n"
+ " But be careful on the news release of Microsoft.\n"
+ " We are planning to release next new bugs soon!!");
System.exit(0);
}
System.exit(1);
}else if(OS==Linux){
while(!kernel.isRunNormally()){
Patch thePatch = kernel.hackBy(me);
kernel.patch(thePatch);
try{
kernel.run();
}catch(AnyException e){
core.trace();
}
}
All.notifyAll(thePatch);
System.out.println("The kernel is now run temporaly.\n"
+ " Just wait next release.");
}
どうでしょう？
Re:まるで (スコア:0)
Re:まるで (スコア:1, 参考になる)
うーん、Linux カーネルって昔からそうだろ。
Linux カーネルのリリースエンジニアリングが腐ってるのは
昔からだし、誰もまともなリリースエンジニアリングを
期待してもいないから、Linux の場合、そのあたりは
ディストリビュータが仕方なくやるのが伝統。
裸のカーネルを持ってきても怖くてそのままじゃ使えない。
必ず自分で検証するか、ディストリビュータが検証したカーネルを
使うのが、痛い目を見ない方法です。
まあもっとも、どんなソフトだって、バージョンを変更するときは
多かれ少なかれ自分で検証が必要だけどな。
Re:まるで (スコア:1)