Path: sran2!katsu From: katsu@sra.co.jp (WATANABE Katsuhiro) Message-ID: Date: 23 May 91 12:11:16 Organization: Software Research Associates, Inc.,Japan In-reply-to: utashiro@sran84.sra.co.jp's message of 20 May 91 08:19:17 GMT Newsgroups: sra.os.unix Subject: Re: File system fragmentation Distribution: sra References: <1349@sran251.sra.co.JP> <326@sran84.sra.co.jp> <330@sran84.sra.co.jp> 記事 <330@sran84.sra.co.jp> で utashiro@sran84.sra.co.jp (Kazumasa Utashiro) さんいはく > 小さいファイルが使うフラグメントの数はもちろん変わりません。 > 問題なのは、使われていないかけらのフラグメントです。newfs す > ると、検索の加減で多少は無駄な「余剰フラグメント」が少なくな > るような気はします。tunefs(8) するという手もあります。 　ここで tunefs するというのは、「tunefs -o space として fragment 割り当ての戦略（optimization preference）を変える」 ということでしょうか？もしそういう意味だとすれば、 これは普通の場合あまりうまくいかないのではないでしょうか？ 　というのは、カーネルが optimization preference を動的に変化させて しまうことがしばしば起きる（と私は思っている）からです。 　newfs -o space などで作ったファイルシステムでも、新たなブロックが 割り当てられようとする時に fragment の占める領域が最小フリー領域の 半分よりも小さければ、カーネルが勝手に時間における最適化の戦略を 選ぶようにしてしまいませんか？ 　（逆の場合すなわち、fragment の占める領域が大きくなってくると、 自動的に領域の大きさにおける最適化の戦略が選ばれるということの方は、 これは文献[1]pp.219 にも触れられているから確かでしょう。） 　あ、禿げるかな………？この程度ならまだまだ大丈夫ですよね？ 参考文献 [1] Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, John S. Quarterman "The Design and Implementation of the 4.3BSD UNIX Operating System" Addison-Wesley, ISBN 0-201-06196-1 -- ----____----____ 渡邊克宏＠ソフトウェア工学研究所