毎日取っている MySQL のダンプのサイズが、ある日を境に極端に小さくなった。
試しにコマンドを叩いてみると

うわっ！
恐ろしいメッセージ・・・。
このマシンはメモリを 4GB 積んでいるので、innodb_buffer_pool_size には半分の 2GB を割り当ててたんだけど、これが原因だろうな。
そこで実メモリの 4 分の 1 まで減らしてみたら、今のところ大丈夫そう。
いや〜、久しぶりに焦った。
ダンプが取れないままじゃ年を越せないもんねぇ。

とある MySQL の環境を別のマシンに移動したときに、設定は間違ってないはずなのに接続できなくなった。

サブネットで接続元を許可しているから、環境を移動しても特にここの設定を変更する必要はないはずだった。
マニュアルによると、このパターンにハマったときは

を実行して、MySQL が持っているホスト名キャッシュをクリアしたら治るとのこと。
でも試してみたらダメ。
そこで、my.cnf に

を書いて MySQL のデーモンを再起動する方法を試したら解決した。
この後 skip-name-resolve を消しても問題なかったので、ひょっとしたら mysqladmin flush-hosts を実行した後はデーモンを再起動しないといけないのかもしれないね。

/proc/acpi/battery/BAT0 の下にあるバッテリー情報を眺めていると、それぞれの値が何を表しているのか知りたくなった。
別に知らなくても何の不都合もないんだけどね。
まぁ、何かの役に立つかもしれない。
家にある ThinkPad X61 の省電力マネージャーにはバッテリーの詳細情報が日本語で出ているので、そっちと見比べてみよう。
実はこれだけで全部分かると思っていた。
が、甘かった。
省電力マネージャーには出てない項目があったり、意味がよく分からないものがちらほら。
ということで、かなりざっくりまとめてある。
興味本位のメモなので自分はいいんだけど、こっち方面には疎いから鵜呑みは危険だ。
間違っているところがあったら教えてほしい。

内容とは関係ないけど、不思議だったのはシリアル番号。
４桁しかない。
バッテリーの表面に書かれている番号とは全然別物だし。
何でだろ。

Ext2 の頃は１つのディレクトリ内に作れるファイル数の話がよく出てきてたけど、Ext3 になってからはまったく聞かなくなったね。
ちょっと興味があったのと、とある検証のために Ext3 上のディレクトリにファイルを大量に作ってみた。
サイズは 10KB でファイル名は連番だ。
環境は、HDD が Western Digital WD800JD-75MSA3 80GB、CPU が Core2 Duo E4500 2.20GHz、メモリが 1GB のマシンに CentOS 5.4 という構成。
負荷がかかるのを予想して HDD は古いものしか使えなかった。
ファイルを作る前の状態を載せておこう。

実際にやってみると、30 万個を過ぎた頃から ls の結果が表示されるまでの時間がだんだんのびてきた。
70 万個辺りで ls の結果が表示されるまで 1 分程度。
100 万個を過ぎると軽く 2 分以上かかるようになった。
また、この辺りからファイルが作られるスピードが落ちてきた。
I/O ウェイトが 50% 前後まで上昇したり下がったりの繰り返し。
そして、150 万個まで作ったときに、ls が 10 分待っても返ってこないことに気づいた。
Ctrl+C も効かないので kill するしかない。
ただしファイルは問題なく作ることができる。
この後、結局 1300 万個以上作ってみたけど、ls したりしなければ特に問題なし。
もう一度 df の結果を載せておこう。

この結果からも分かるように、i ノードさえ残っていればファイルを作れるようだ。
ちなみに ls が使い物にならなくなってからでも、例えば vi で個別にファイルを開いて編集したりするのは問題なかった。
面白くない結果になってしまったけど、まずはひと安心ってところだな。

以前 .svn/tmp が開けないエラーが出て、一旦リポジトリを消してから作り直したことがあった。
そのときは珍しいエラーなのかと思っていたんだけど、近頃、似たようなパターンで svn update がちょくちょく引っかかるようになった。

で、言われた通り cleanup してみると

とのこと。
クライアント側の操作がトリガーになっているんだろうな。
メッセージに出てる .svn/tmp ディレクトリを作ってから svn cleanup と svn update したら通ることは分かってる。
でも、どのディレクトリで起こるかが事前に掴めないんだよねぇ。
仕方がない。
mkdir するスクリプトを cron で回して回避しよう。

根本的な解決になってない？
まぁ、そこは大人の事情というやつで。