Article 340 of fj.news.system: Path: news2.sra.co.jp!katsu From: katsu@sra.CO.JP (WATANABE Katsuhiro) Newsgroups: fj.news.system,fj.sys.sun Subject: Re: block size for NewsServer Supersedes: Date: 07 Oct 1998 01:25:53 GMT Organization: Software Research Associates, Inc., Japan Lines: 154 Message-ID: <6veogg$l65$1@sranhh.sra.co.jp> References: <4urfi4$hm7@hello.chuo.longdist.ntt.jp> <4v2t23$81@rush.marie.iijnet.or.jp> NNTP-Posting-Host: sras49.sra.co.jp In-reply-to: Hiroshi KISE's message of 13 Aug 1996 07:52:46 GMT Originator: katsu@sras49 Xref: news2.sra.co.jp fj.news.system:340 fj.sys.sun:3796 あまりのフォローの遅さが議論の妨げになっていたらごめんなさい。 投稿時に化けた を superserdes します。 記事 で kise@imicom.or.jp (Hiroshi KISE) さんいはく > さて、ニュースの記事のように、1つのファイルが平均1kバイト(未確認)の > 場合、デフォルトのblock size(Solaris2.4だと8192バイトらしい)では > 無駄になってしまうそうです。 > > そこで、1ブロック2048バイトほど(この値はINN FAQのpart7より。“newsfs”で > 検索すること:-)でnewfsしなおしてみようと思います。この時、何か問題や注意 > する点がありましたら、教えてください。 「無駄」に関して言えば、block size より、fragment size の方が重要です。 そもそも、FFS 由来のファイルシステムのほとんどのものは、blocksize を 2048 にできません。FFS に由来する「Solaris2.4」の ufs でも同様じです。 奇妙に思って INN FAQ Japanese Version:1.04 Part 7/9 を見ましたが、 4096/512 という記述はあっても、 2048 などという記述は見つかりません。 想像するに喜瀬さんは、すぐそばの bytes/inode の話を、block size (及び fragment size) の話と混同なさったのではないでしょうか。 参考に INN FAQ を引用しておきます。 ================ Subject: (7.24) inodesが足りなくなりましたが、まだディスクは空いています もしディスクにまだ余裕があるのにinodeが無くなってしまったのであれば、 スプールがあるパーティションを再構築することを考えるべきです。 ファイル・システムのデフォルトの設定ではほとんどの場合4k/inodeの値が使 われます。個々の記事の大きさは平均で3k以下ですから、ニュース用のファイ ルシステムにはこの値は適当ではありません。ですから、一inodeあたり2kの 設定でスプールを構築してください。 もし再構築するのなら、block/fragsizeの値を4096/512に調整することもでき ます。こうすると8192/1024の場合よりも多くのディスク空間を利用できるよ うになります(こうすると4kよりも大きな記事に対しては8k/1kの場合よりも多 少遅くなりますがこれは小数派です。この設定はalt.binariesに割り当てられ たパーティションには使ってはいけません)。 ================ おわり 引き続くフォローのいくつかも、この喜瀬さんの混乱をひきずっています。 記事 で aki@noc.titech.ac.jp (飯島 昭博 /Iijima Akihiro) さんいはく > > さて、ニュースの記事のように、1つのファイルが平均1kバイト > > (未確認)の場合、 > > 統計とって欲しい。 喜瀬さんも tnn.netnews.stats の情報から記事の平均サイズを割り出した ようですが、かつて、 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 に記事の長さの分布を示したことがあります。平均 2780 bytes/article で、 標準偏差は大きく 6026.74でした。当該の記事は http://www.sra.co.jp/people/katsu/article/220.txt で参照することができます。 ついでに、ニューススプールにおいて、8192/1024 FFS と 4096/512 FFS の 空間効率の違いについては、過去に考察と実験を行なって投稿したことが あります。 http://www.sra.co.jp/people/katsu/article/#filesystem の近辺に置いてある記事を参考にしてください。 記事 で kise@imicom.or.jp (Hiroshi KISE) さんいはく > メイルでのフォローをもらいましたが、UFSでは、下の値も関係してくるようです。 > -f fragsize The smallest amount of disk space in > 最初に投稿した記事では、下のオプションだけみていました。 > -b bsize The logical block size of the file sys- > Solaris2.xでは、デフォルトのままでも効率よくディスクが使用できる > ということになるのでしょうか? 普通に Solaris をインストールしたり、newfs する時に特に option を 指定しないと、8192/1024 のファイルシステムができあがると思います。 ニューススプール用には、この設定は好ましくないことが多いでしょう。 (ただし、最近の INN で CNFS を使っている場合は、全く別の考察が 必要です。) ちなみに、arch -k が sun4u の場合、fragment size が 512 の ファイルシステムは、事実上 mount できません。pagesize が 8192 である sun4u では blocksize が 8192 のファイルシステムしか mount できないといわれていますが、fragment が 512 ということは block size を 8192 にすることは不可能だからです。 記事 <4urfi4$hm7@hello.chuo.longdist.ntt.jp> で tosinori@techno.chuo.longdist.ntt.jp (Toshinori ISHII) さんいはく > > そこで、1ブロック2048バイトほど(この値はINN FAQのpart7より。“newsfs”で > > 検索すること:-)でnewfsしなおしてみようと思います。この時、何か問題や注意 > > する点がありましたら、教えてください。 > > 以前、linux を使っていたときに 1024 バイトにしたことが > あります。しかしちょっと大きなパーティションを作ると > i-node の数が上限を超えてしまった、ということがありました。 これも bytes/inode の話のようですね。 > sun ではやったことがないのでわかりませんが、まぁ似たような > もんでしょう。 違うと思いますよ。SunOS 5.X の ufs は、大規模なファイルシステムへ 適用するために、いろいろと拡張が行われています。 そもそも、Linux の ext2fs と、Sun の ufs は、仕様も違いますし、 実装上も共通の祖先を持ちません。ですから、どちらかの振舞いから 他方の振舞いを議論するのは無意味でしょう。 記事 <4v2t23$81@rush.marie.iijnet.or.jp> で yanagi@rush.marie.iijnet.or.jp (Hideki Yanagisawa) さんいはく > PC-9801DA+FreeBSD205+inn1.4unroff4でUUCPをしています。news spoolのi-node > が不足し、一時はスプールがつぶれたことがありました。そのときは、FreeBSDの > インストーラにnewfsをおまかせしておりました。その後、FreeBSDの話ですが > newfsをやり直して以来何ら問題ありません。対処方法は > > newfs -i 512(or1024) /dev/..... > > を行いました。df -iで毎日確認していますが、まだまだ余裕があるようです。 これも bytes/inode の話ですね。 記事の平均サイズ(言い換えてみれば、inode あたりのバイト数)は 3K 弱 ですから、-i 512 や -i 1024 はかなり小さい(余裕ある)設定です。 news spool では記事数(ファイル数)が十分多いので、統計からのゆらぎや ずれはいつも小さいでしょう。INN FAQ の言うとおり、2048 bytes/inode 程度で十分だと思います。 なお、newfs の -i (bytes/inode) は、2の冪乗にこだわる必要は全く ありません。 -- 渡邊克宏@SRA