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: <KATSU.92Jan21190539@sran14.sra.co.jp>
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 では、空きブロックの多寡が書き込み時の
性能に影響するはずである。また、満杯近くで作られたファイルは
ブロックが局所化されず、結果的に読み込みの性能にも影響するはずである。
これらの点からいっても、ファイルシステムを極限状態で使うのは
よした方がよい。

----____----____
渡邊克宏 SRAソフトウェア工学研究所