Path: galaxy.trc.rwcp.or.jp!sokai!caepost!inet-gw!cae-gw!ntt-twins!nttlab!icot32!sh8810!ascgw!ascwide!wnoc-tyo-news!sranha!sran265!katsu From: katsu@sran14.sra.co.jp (Katsuhiro Watanabe) Newsgroups: fj.unix,fj.news.adm Subject: A filesystem have overflown in spite of avail>0 Message-ID: Date: 21 Jan 92 10:05:39 GMT Sender: news@sran265.sra.co.jp Followup-To: fj.unix Distribution: fj Organization: Software Research Associates, Inc.,Japan Lines: 65 Xref: galaxy.trc.rwcp.or.jp fj.unix:1205 fj.news.adm:496 X-originally-archived-at: http://galaxy.rwcp.or.jp/text/cgi-bin/newsarticle2?ng=fj.unix&nb=1205&hd=a X-reformat-date: Mon, 18 Oct 2004 15:18:22 +0900 X-reformat-comment: Tabs were expanded into 4 column tabstops by the Galaxy's archiver. See http://katsu.watanabe.name/ancientfj/galaxy-format.html for more info. （Followup-To: に注意） 　 　ファイルを作ろうとした時に、対象となるファイルシステムを df(1) で 見た時の avail が 0 でないにもかかわらず、file system full になる事態を 経験しました。お正月の景気づけに事例を投稿します。 　機械は Sony NEWS-3860 (NEWS-OS 4.1) ですが、BSD の Fast File System （に由来するもの）を使っている時に共通の問題です。 [1] 事故の状況 　問題のファイルシステムはニュースのスプールであり、NNTP によって 記事が転送されてくる。nntpd は記事を受けとる前にディスクの 残り容量を statfs(2) で監視していることから、記事の受け取りに関する ディスク溢れは生じないと（少なくとも私と、他にもう一人は）信じていた。 　このファイルシステムは、blocksize/fragmentsize が 4096/512 で、 minfree(free-space reserve) を 1% にしてあった。 　ある日、記事の受け取り中に溢れが生じた。その時点で df(statfs(2) を 調べるのと同じこと）すると、 # df /var/spool/news Filesystem kbytes used avail capacity Mounted on /dev/sd10e 263303 259190 1479 99% /var/spool/news と、まだ 1479K かけそうな様相を示している。（従って nntpd は無罪。） fsck してみると、 # fsck /dev/sd10e : : : : : : : 98102 files, 518381 used, 8226 free (8226 frags, 0 blocks, 1.6% fragmentation) 　というように、実は、もはや空ブロックは一つもなく、沢山残った フラグメントだけが 1479K の「まぼろし」を見せていただけであった。 8226 * 512 = 4113K （空きフラグメントの合計） 　4113 - (263303 * 1%) = 1479 分だけ avail になっているわけである。 　実際、フラグメントサイズを越える大きさのファイルは file system full に なって一切作ることができなかったが、フラグメントサイズ以下の大きさの ファイルは、まだいくつでも作ることができた。 [2] 考察と教訓 ・statfs(2) は、空き容量をフラグメント単位で返すだけであって、 あとどれだけ書き込めるかを教えてくれるわけではない。 （df の出力についても同様） ・他で同種のトラブルを聞かないのは、普通は free-space reserve が 十分大きいため、ブロックを使い切るよりも f_bavail が 0 になる方が 先だからだろう。 ・今回のようなことが原因による一般ユーザーでの書き込み不能を 予防するための方法論として、fsck が出す、xxx% fragmentation の xxx% よりも free-space reserve を大きくしておくことを提案する。 こうしておけば、フラグメント分は free-space reserve 分に埋もれて、 一般ユーザーにとって無関係になることが保証される。この条件が 満足されているかどうかの監視も、fsck してみるだけなので容易である。 ・BSD の Fast File System では、空きブロックの多寡が書き込み時の 性能に影響するはずである。また、満杯近くで作られたファイルは ブロックが局所化されず、結果的に読み込みの性能にも影響するはずである。 これらの点からいっても、ファイルシステムを極限状態で使うのは よした方がよい。 ----____----____ 渡邊克宏　ＳＲＡソフトウェア工学研究所