Article 1634 of japan.netnews: Path: news2.sra.co.jp!katsu From: katsu@sra.CO.JP (WATANABE Katsuhiro) Newsgroups: japan.netnews Subject: blocksize/fragmentsize of news spool (Re: POST : LL-N4-09.JPG(1/1)) Supersedes: Date: 06 Oct 1998 22:32:17 GMT Organization: Software Research Associates, Inc., Japan Lines: 113 Message-ID: <6veo4u$krv$1@sranhh.sra.co.jp> References: <5aj58u$ook@pit-inn.shinjuku.tokyonet.ad.jp> <970107230849.M0104793@marie.iijnet.or.jp> NNTP-Posting-Host: sras49.sra.co.jp In-reply-to: Kouhei Matsuda's message of 7 Jan 97 14:09:06 Originator: katsu@sras49 Xref: news2.sra.co.jp japan.netnews:1634 あまりのフォローの遅さが議論の妨げになっていたらごめんなさい。 Newsgroups: から japan.yoso を削りました。 投稿時に化けた を supersedes します。 記事 <970107230849.M0104793@marie.iijnet.or.jp> で jetta@marie.iijnet.or.jp (Kouhei Matsuda) さんいはく > 関係ない話ですが、newfsするときのブロックサイズを8192のまま > にしてDiskの半分以上がブロックギャップというサーバーもあちこ > ちで見かけます。 これは変でしょう。あるいは、強調しすぎの表現かと思います。 「newfs」、「ブロックサイズを8192のまま」ということなら、BSD 由来の FFS （および FFS から派生したもの）での話ですよね。（以下これを仮定。） ニューススプール用のパーティションを newfs する時の block size と fragment size は小さくすべきという点では同意できますが、「半分以上が ブロックギャップ」という状態は、私の経験や統計とは矛盾します。 まず、空間利用効率については block size 共々 fragment size が大きく 効きます。「ブロックサイズを8192のまま」にしている人は、意図的に そうしているわけではなく、デフォルトを使っているわけでしょう。つまり この場合、fragment size は 1024 になっている場合がほとんどです。 次に、ニュース記事の長さの分布は下のような形です。 http://www.sra.co.jp/people/katsu/article/220.txt より： > From: katsu@sra.co.jp (WATANABE Katsuhiro) > Message-ID: > Date: 15 Aug 93 20:38:43 > Newsgroups: fj.news.lists,fj.news.adm > Subject: statistics of articles' filesize > [fj] 総記事数 4627 平均サイズ 2780Bytes 標準偏差 6026.74 > > バイト数 度数 > 0- 127 0 > 128- 255 0 > 256- 383 10 * > 384- 511 20 ** > 512- 639 39 **** > 640- 767 92 ********* > 768- 895 128 ************* > 896- 1023 203 ******************** > 1024- 1151 293 ***************************** > 1152- 1279 313 ******************************* > 1280- 1407 379 ************************************** > 1408- 1535 358 ************************************ > 1536- 1663 346 *********************************** > 1664- 1791 257 ************************** > 1792- 1919 252 ************************* > 1920- 2047 215 ********************** > 2048- 2175 207 ********************* > 2176- 2303 161 **************** > 2304- 2431 117 ************ > 2432- 2559 122 ************ > 2560- 2687 113 *********** > 2688- 2815 103 ********** > 2816- 2943 94 ********* > 2944- 3071 77 ******** > 3072- 3199 55 ****** > 3200- 3327 57 ****** > 3328- 3455 42 **** > 3456- 3583 36 **** > 3584- 3711 41 **** > 3712- 3839 26 *** > 3840- 3967 28 *** > 3968- 4095 31 *** （山の裾野の部分は略したので、必要な方は元記事にあたってください。） このような分布のファイル群を 8192/1024 FFS 上に置いたとき、 fragment や block 内でファイルに使われない無駄な領域 （「ブロックギャップ」）を計算してみると、約 26% です。 全体の「半分以上」とは、とても言えない数字でしょう。 4096/512 FFS にすれば約 13% で、大幅に減ることは確かです。 ちなみに、8192/1024 から 4096/512 に変えると空間利用効率がどのくらい 上がるかというと、全ファイル量総計比で、おおよそ１割です。詳しくは、 http://www.sra.co.jp/people/katsu/article/222.txt にある、 Message-ID: Date: 16 Aug 93 11:05:52 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? を参照してください。 余談ですが、SunOS の sun4u カーネルアーキテクチャーの元では、 blocksize を 4096 にしたくてもできません（mount ができない）。 pagesize が 8192 になっていて、カーネルがブロックを扱う時の単位が ページだからだそうです。 いずれにせよ、こうした技巧や知識は、INN の CNFS が広まってくると、 廃れてしまうのかもしれません。 > ています。システムは、僕が改造したbnews-2.11.xxで、CPUは、 > 4.25mi/sが２台です。nntpなど使わずに、gnuのuucp-1.06.1での > uucp over IP です。これで十分です。 2000 年以降も動きそうですか？松田さんの記事のヘッダーは > Date: 7 Jan 97 14:09:06 GMT と、年が２桁になっているので心配です。 -- 渡邊克宏＠ＳＲＡ