Path: sran265!katsu From: katsu@sran14.sra.co.jp (WATANABE katsuhiro) Message-ID: Date: 9 Nov 92 18:09:04 Organization: Software Research Associates, Inc.,Japan In-reply-to: image@cs.titech.ac.jp's message of 6 Oct 92 05:23:08 GMT Newsgroups: fj.unix Subject: Re: Q. about /etc/pstat Distribution: fj References: フォローの遅さなら jp で十指にはいるであろう渡邊@SRAです。 記事 で image@cs.titech.ac.jp (Takashi Imaizumi) さんいはく > >  process file の sticky bit(cf. chmod(2))が立っている場合は、例外的に > > フリーリストに接続されない。 > >  したがって、これに加えて process file の vnode が rnode と結び付いて > > いるのではない(つまり NFS マウント先にあるわけではない)場合には、 > > (よしんばテーブルが一杯になっても)内容が捨てられたり、他のテキスト用に > > 使い回されるようなことはない。 > > ここは、「sticky bitが立っているファイルのvnodeがrnodeと結び付 > いていない」という意味ですよね。  そういう意味で書きました。しかし、次でも述べるように、「これに加えて、 … vnode が rnode と結び付いているのではない … 場合には」という条件は、 私の誤りで、全く無関係でした。  つまり、sticky bit が立った text は(rnode が関係していようと inode が関係していようと)、テキストテーブルがあふれる時でさえ 頑固にテーブル内に居座ります。 > >  上記のように vnode に関する活動のためにフリーなエントリーが > > クリアされて not used になる場合、もはやキャッシュとして機能しない > > ということで、一気にフリーリストの先頭にまわされて優先的に > > 使われるようになっている実装 (NEWS-OS 4.1C/R) も存在する > > 実は、ここにまだ疑問が残っています。付けて頂いたtextfプログラ > ムは、テキストテーブルのフリーリストをたどってくれるのですが、 > あるマシン(このマシンは/usr/local/binをNFSマウントしているので、 > not usedになっているエントリもたくさんあるはず)では、フリーリ > ストにVPTRがNULLのエントリがほとんど出て来ないのです。  まず先に確認すると、上でかいた NEWS-OS 4.1 の実装における 「上記のように … になる場合、フリーリストの先頭にまわされて」 というのは、rnode が解放される [NFS case] 場合だけでなく、inode が 解放される [local case] 場合も含んでのことです。具体的には、inode だろうと rnode だろうと、unlink や unmount に起因して vnode の解放が 起これば、つられて not used になったテキストエントリーキャッシュは フリーリストの先頭に行くはずです。  しかし、私が記事 で次のように 書いたのは誤りでした。 > (3)フリーなエントリーと vnode との関係 > [NFS case] ft が vnode を介して rnode "rn" と関係していたとする。 > rnode 一般に言えることとして、どこからも参照されていないものは > カーネルによって適当な時期に回収されるが、inode の場合と違って > フリーなテキストエントリーと関連している rnode/vnode も回収されて > しまうようである。もし rn についてこうした回収が起きると、ft の中身は > クリアされる。 普段私は amd を利用しているのですが、amd によって unmount が起きた (そしてそのファイルシステムの rnode が全て無効になる)状況を、 カーネルによってrnode が勝手に回収されるものと誤解したものです。 皆さんごめんなさい。  unlink や unmount などの正当な(?)理由なくして、上でいう 「ft の中身はクリアされる」ようなことは起こりません。  今泉さんの疑問に戻ると、not used なエントリーがない方が自然だと いえます。 > そのため > か、/etc/pstat -Tの最初の数字がusedの値(これはmaxよりもかなり > 小さい)に近付いた時点でtext table fullのメッセージを出していた > のです。これはうまくフリーリストの先頭につながれていないという > 意味なのかな? ちなみにOSはNEWS-OS 4.1Rです。  フリーリストの先頭が used かどうかでエントリーの割り当ての戦略が 変わるようには思えない(かつ、そういう経験が私にはない)ので、 各エントリーが used かどうかあるいは used のエントリー数がどうかより、 フリーリストの長さがどうなっているのかの方が問題だと思います。 text table full になった時、フリーリストの長さはどうなっているか、 あるいは _xhead が何を指しているのか観測してみてください。 (text table full ならそのままでは dbx/adb が走らないので、 background にはべらせておくか、sticky bit を使うとよいでしょう。)  なお、この件は NEWS-OS 4.1 のバグに起因する可能性がある旨を、 fj.sys.news の記事 で 指摘しておきました。 -- 渡邊克宏@SRAソフトウェア工学研究所