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 で十指にはいるであろう渡邊＠ＳＲＡです。 記事 で 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 になったテキストエントリーキャッシュは フリーリストの先頭に行くはずです。 　しかし、私が記事 で次のように 書いたのは誤りでした。 > （３）フリーなエントリーと 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 の記事 で 指摘しておきました。 -- 渡邊克宏＠ＳＲＡソフトウェア工学研究所