新城＠筑波大学情報です。こんにちは。

In article <u7jmtn108.wl%reo@juno.dti.ne.jp>
        Hiroki Kashiwazaki <reo@cc.hokudai.ac.jp> writes:
> 今年も肥大するに肥大した nfslog_workbuffer_log_in_process が/varを
> 食い尽くしてしまったのですが、cron あるいは logrotate で対処するの
> はまた後回しという事で、mv して touch して chmod, chown, chgrpなど
> して対処した訳ですが、/var 以下からその巨大 log を別パーティション
> に移動したにも関わらず、df の結果が反映されず、99%使用のままになっ
> ています。

これは、Sun だけの問題ではなくて、Unix 一般に起こり得る話で
す。原因としてありそうな話としては、こんなことかなあ。

(1) nfslog_workbuffer_log_in_process に別に実リンクがある。
(2) nfslog_workbuffer_log_in_process を開いたままのプロセス
    がいる。

rm コマンド (mv で別のパーティションに移動も同じ) だと名前は
消しますが、ファイルの実体は消えません。実リンクが１つでもあ
れば、実体は消えませんし、実リンクなくてもどれかのプロセスが
ファイルを開いている状態だと、やはり実体は消えません。内部的
には、実リンクと同じで参照カウンタが上がっているので。

(1) か (2) の違いは、rm (mv) する前に ls -l で実リンクの数を
調べる必要があったかも。まあ、大きなファイルなので後でも
探せるのでしょう。(2) の問題としてとりあえず対応するといいか
も。つまり、ファイルを開いていそうなプロセスを kill するとか、
システム全体を再起動するとか。

> シンボリックリンク関連かと思い、/varからの、/varへのシンボリックリ
> ンクも洗いざらい調べてみましたが特に問題もなく、お手上げなので再起
> 動したところ、きちんと40%程度の空きが確保されるに至りました。

あ、(2) だったみたいね。ファイルの実体の解放には、シンボリッ
ク・リンクは関係ありません。

> /var が RAID1 で構成されている事に原因があるのかとか考えましたが、
> どうにも原因が分かりません。gdf や pkgadd が何を見ているのかという
> ところに問題の根本がありそうな気はするのですが…。問題は解決された
> 訳ですが、後学のためにも原因や解説などお寄せ頂ければ幸いです。

RAID は関係ありません。RAID ではないディスクでもそういう話は
あります。

＼＼　新城　靖　（しんじょう　やすし）　＼＼
＼＼　筑波大学　電子・情報　　　　　　　＼＼