それにしても虚弱すぎる lfs。いっぱいファイルを書こうとするとほぼ確実に死んじゃう。
今回は作業用に afs 用の /vicepa が ffs で空いていたのでそこを使ったが、この調子で大量にファイル書こうとするたびに死ぬんじゃ ffs の領域が必須だ。 lfs を ffs に戻すなら、作業するのはまだファイルが少い今しかない。
しかし折角の lfs なので、なんとかパラメータチューニングで使えるようにならんかと調べてみた。
一つ見つかったのは、 sync の delay を敢て0にするという方法(tech-perform: LFS "smooth" syncer workaround/performance tuning)。
よく判らんが、書いたり消したりが一杯続く時は、書いてすぐ sync せずにちょっと待った方がパフォーマンスがいいとか考えたんだろう。それを lfs の場合は即座に書いたほうがいいはず、という狙いのようだ。問題は、 lfs 以外にも全域に影響が及びそう、ということ。
ところが、実はこういう修正が既に commit されている(The NetBSD CVS Digest)。
lfs 限定で、上の delay しないを default でやろうということのようだ。なんだ。既にやってあるんじゃん
もう一つ見つけたのがこれ。こっちは全く理解できない。
Nabble - LFS stability: kern/36608
current-users: Re: processes consuming all CPU during I/O on LFS
ただ、調べてみたらこの値が0になっていた。segment sizeは上の例と同じだったのでこれを64で設定してみる…。
するとすっかり安定しているんですけど?!
これなら lfs で運用できますよ?
…しかし玄箱うるさいなぁ。
[referer: [an error occurred while processing this directive]]