Path: sran265!katsu From: katsu@sra.co.jp (WATANABE Katsuhiro) Message-ID: Date: 16 Aug 93 11:05:52 Organization: Software Research Associates, Inc.,Japan In-reply-to: shimano@lebia.tokyo-u-fish.ac.jp's message of 26 Apr 93 04:17:11 GMT Newsgroups: fj.sys.sun,fj.unix,fj.news.adm Followup-To: fj.unix Subject: Re: How to increase i-node for a news spool partition on Sun3? Distribution: fj References: <175@s4201.tokyo-u-fish.ac.jp> 要約: 当然ニューススプールは fragment size が小さいほど空間効率がよい　あまりのフォローの遅さが議論の進行を妨げているなら失礼。記事 <175@s4201.tokyo-u-fish.ac.jp> で shimano@lebia.tokyo-u-fish.ac.jp (Akitsugu Shimano) さんいはく > Chiaki Ishikawa (ishikawa@personal-media.co.jp) wrote: > > : 質問ですが、このパーティションのi-nodeを増やすにはなにか特別な方法がい > : るのでしょうか？ > あるファイルシステム(仮に/dev/xd0gとする)についてファイルシステムを > 構築する場合， > > # newfs /dev/rxd0g > > とすると > > # newfs -c 16 -f 1024 -i 2048 -t 16 /dev/rxd0g > > と判断される(デフォルト値)．ここで > > -c シリンダグループあたりのシリンダ数(1～32) > -f フラグメントサイズ (512～8192) > -i 1つのiノードあたりのバイト数 > -t 1シリンダあたりのトラック数 > > である．　-f について述べるなら、関係深い -b についても触れたほうがいいでしょう。 -b 8192 がデフォルトですね。　それから、ブロックサイズが 4096 か 8192 なのだから、フラグメントサイズは（SunOS の mkfs(8) には確かに 512 から 8192 と書いてはあるんですが）事実上 8192 にできないと思います。 > JUNETのニュース用スプール等， > サイズの小さいファイルが多数存在するようなファイルシステムでは， > SunOS 4.0.3のnewfsコマンドのデフォルトではiノードが不足する可能性があるため， > たとえば > > # newfs -c 8 -f 1024 -i 512 /dev/rxd0g > > として(-c，-iをデフォルトよりも小さく設定して)iノード数を増やす． > ところが，ディスクの機種によっては(例:Fujitsu-M2372K) > -tの値がデフォルト(16)のときにiノードが増やせない． > > 対策等 > > -tの値を26とする． > > # newfs -c 8 -f 1024 -i 512 -t 26 /dev/rxd0g 　私のところでは、ニューススプールを newfs するときには -b 4096 -f 512 でやっています。（正確には Sun ではなく Sony NEWS の FFFS ではありますが。）これは「ニューススプールでは速度より空間利用効率を重視したい」という私のサイトでの選択によるものですが、この方針は他の多くのサイトにもあてはまるように思います。速度も大きくは違わないものと踏んでいます。　もしかしたら、Sun では fragment size を 1024 にしておく（あるいは 512 にできない）なんらかの理由があるということなんでしょうか。　フラグメントサイズ／ブロックサイズが 1024/8192,1024/4096,512/4096 であるようなファイルシステム上にニューススプールを置いたときの、ディスク使用量の違いを見積ってみましょう。もちろん 512/4096 ファイルシステムが一番効率よいという直感を持ってもそれは間違っていませんが、推論過程が必ずしも trivial でなく、またニューススプールの統計に基づいた知識が必要なはずなので、議論の対象にしておきます。以下のようなことを仮定してよいと思います。 (A) expire の期間が数日より長く、数百日より短く、その結果スプールにあるファイルの集まりの中でディレクトリーが占める割合は小さく、サイズも小さい。 (B) 記事を保持するファイルのサイズは小さいものが多い。 (C) 記事を保持するファイルのサイズについて 512, 1024, 4096, 8192 など 2 のベキ乗の剰余を調べたとき、一様に分布している。（実際はかなり偏りがある。）以下の説明で出てくる数のうち、魔術的な数が出現するのを嫌って NDADDR (cf. ) を使って表記した部分がありますが、多くの機械ではこれは 12 です。統計的数値の中で NDADDR に影響を受けるものについては、 12 を仮定して調査をしてあります。 [1] 1024/8192 ファイルシステムと 1024/4096 ファイルシステムの違い　ブロックサイズに由来する使用量上の違いは、ファイルの大きさによって以下の small, middle, large, and huge case のようになります。 (small case) サイズが 4096 * NDADDR 以下のファイルについて　フラグメントサイズが同じなので、1024/8192 ファイルシステム上でも、 1024/4096 ファイルシステム上でも、使用するフラグメント数は同じです。 (middle) 4096 * NDADDR < ファイルサイズ <= 8192 * NDADDR のようなファイル　1024/8192 ファイルシステム上では間接ブロックを使わずに表現できるのに、 1024/4096 ファイルシステム上では間接ブロックを使うようになってしまい、当然間接ブロック用に 1 block 使用量が増えます。　また、間接ブロックが使われるファイルにはフラグメントが割り当てられないことを思い出すと、割り当て単位がフラグメントからブロックへと大きくなった分、無駄が増えることがわかります。　middle case にあたるファイル f が、1024/8192 FileSys から 1024/4096 FS に移動する時に増えるディスク使用量の期待値を求めてみます。割り当て単位の変化のほうによる使用量の増加は、f のサイズを 4096 で割った剰余によって remainder 0 1024 2048 3172 4096 |-------------|-------------|-------------|-------------| extra space 3 fragments 2 frags 1 frags 0 frags のようになります。この剰余が一様に分布すると考えると、ファイル１個あたりのディスク使用量増加分の期待値は、 1 indirect_block + (3/4 + 2/4 + 1/4 + 0/4)frags = 5.75 frags と見積もることができます。 (large) 8192*NDADDR < ファイルサイズ <= 8192*(NDADDR+4096/sizeof(daddr_t)) 　このようなファイルはどちらのファイルシステムでも（一重）間接ブロックを使っています。　1024/4096 FS の方が、間接ブロックのサイズが半分であるぶん得をします。また、1024/4096 FS では、割り当ての単位であるブロックサイズが小さいので、 1024/8192 FS に比べて無駄が小さくなる可能性があります。　large case のファイルが、1024/8192 FS から 1024/4096 FS に移動する時に *減る* ディスク使用量の期待値を求めると以下のようになります。 (8192 - 4096)Bytes + (4/2 * 0/2)frags = 6 frags (huge) 8192*(NDADDR+4096/sizeof(daddr_t)) < ファイルサイズ　少なくとも 1024/4096 FS では二重間接ブロックが使われることになりますが、こうしたファイルはニューススプールにはほとんどありませんから、無視することにします。　さて、使用量が増えるという middle case と減るという large case で変化量の見積りが偶然同じ程度になりましたが、普通のニューススプールにおいては middle case の方が圧倒的に多い（少なくとも十倍以上の開きがあり、そもそも large case が全然ない場合も多い）のが普通 (cf. 参考文献 1,2) なので、結果として middle case の要素が大きく影響します。ディレクトリーファイルのことが気になる人は仮定 (A) を思い出してください。つまり、 1024/4096 FS と 1024/8192 FS を比べると、1024/4096 FS の方がディスク使用量が増えることとなります。どのくらい増えるかというと、普通は middle case が全記事の 0.2% から 0.5% をあまりはずれないと信じるならば、総記事数 * (0.2% から 0.5% ぐらい) * 5.75 fragments = 総記事数 * (0.01 から 0.03) KByte ぐらいにして大きくは間違わないと思います。　総記事数は、ニューススプールが独立したパーティションに置いてあるという典型的な場合ならば、df -i の inode 数から簡単に十分な精度で予想ができます。 [2] 1024/4096 ファイルシステムと 512/4096 ファイルシステムの違い　間接ブロックを使わないようなファイル（サイズが 4096 * NDADDR 以下、すなわち [1] でいう small case が、1024/4096 FS から 512/4096 FS に移動した時に減るディスク使用量の期待値は、512Byte fragment 単位で 0.5 となるのは明らかでしょう。　記事のうちの 99% 以上をこうしたファイルが占めますから、これが原因によるディスク使用量の減少分はスプール全体で総記事数 * 0.5 fragments(512Byte) = 総記事数 * 0.25 KByte となることが見込めます。 [3] 結論：1024/8192 ファイルシステムと 512/4096 ファイルシステムの違い　[1],[2] の結果を比べてみると、1024/8192 FS の記事ファイル群全体を 512/4096 FS に移動した時に減るディスク使用量は、だいたい総記事数 * (0.22 から 0.24) KB という式で見積もれることになります。　上の式の符号は正ですから、結論として、Fast File System でニューススプールの空間利用効率を重視する方針の場合には、 512/4096 FS を選択すべきであるといえます。　なお、フラグメントサイズやブロックサイズを変えて newfs すれば、ファイルシステムの全容量も変わるわけですが、　　「特定のパーティションを newfs して得られるファイルシステムの全容量は、　　フラグメントサイズやブロックサイズが変わっても同じか、あるいは　　フラグメントサイズやブロックサイズの小さいほうが若干多くなる。」という事実をいって、不公平な比較ではないことを主張しておきます。 [4] 確認実験　上の論理の説得力を補強するため、1993年6月のある日のスプール (comp.*) を dump し、いろいろなフラグメントサイズ／ブロックサイズのファイルシステムに restore すると、ディスク使用量がどう変わるか実験した結果を示します。　comp.* の expire は６日に設定してあり、その結果、対象となったのはディレクトリを含めて 37337 個のファイルで、うちディレクトリは 540 個でした。 fragmentsize/blocksize used(fragments) used(KBytes) 1024/8192 99255 99255 1024/4096 99939 99939 512/4096 182085 91043 　というように確かに 8MBytes ばかり儲かっていることが観察できます。（ちなみに、 small case(size <= 49152): 37181 files middle case(49152 < size <= 98304): 141 files large case(98304 < size <= 4243456): 15 files huge case(4243456 < size): 0 files となっていました。ディレクトリはすべて small case に属します。）　ついでにこのスプールを 8192/1024 FS から 4096/512 FS に移したときにもうかるディスク容量の、[3] の式による見積りと現実を比べましょう。　まずは総記事数を決めましょう。普通スプールのファイル数は（上のような分布を調べるのは難しいですが）df -i や fsck の結果などから簡単に推測できます。ここでは上の 37337 というファイル数がわかっているとします。この中からディレクトリーの分をうまく引かなければなりません。この日の active ファイルには '^comp.' というパターンが 495 行あり、ディレクトリがこれとだいたい１対１に対応すると考えると、総記事数は 36842 以下で、しかしあまりこれから離れていない数としてよいでしょう。すると見積り: 総記事数 * (0.22から0.24) = 8105KByte から 8842KByte の間となります。いっぽうで、現実: 99255 - 182085*0.5 = 8213 KByte ですから、まあまあの結果でしょうか。　以上、実際にニュースシステムの管理をやっていらっしゃる方を含めて expert の皆さんの批判や追試などを期待するところです。とりわけ、 middle case に属する記事が全記事の 0.2% - 0.5% というところは *.sources.*, *.binaries.* などの activity との対応を少し詳しく調べるべきかもしれません。参考文献: 1. 定期的に投稿される以下のような記事 > From: newsstats@uunet.UU.NET > Newsgroups: news.lists > Subject: Total traffic through uunet for the last 2 weeks > Organization: UUNET Communications 2. Newsgroups: fj.news.lists,fj.news.adm の記事 -- 渡邊克宏＠ＳＲＡ