[Armadillo:03358] Re: NAND上のファイルへのlsに時間がかかります

[Yasushi SHOJI]

At Thu, 28 Aug 2008 16:49:18 +0900,
Yasushi SHOJI wrote:
> 
> At Thu, 28 Aug 2008 15:21:41 +0900,
> fukunaga wrote:
> > 
> > >もしかすると、完全にGCされていないんじゃないでしょうか？
> > >test.csvを移動すると、どうなります？移動のときに mvではなくて以下のコ
> > >マンドで移動してみてください。
> > >
> > >         $ mv test.csv test.orig
> > >         $ cat test.orig > test.csv
> > >         $ rm test.orig
> > >
> > >この後に lsするとどうなりますか？
> > 
> > 実行しました。するとGCが働くのか、マウント直後のUsedサイズが小さくなり、
> > 52秒だったlsが3秒になりました！！
> > ただ、その後アンマウント・マウントを繰り返しても変化はありませんでした。
> > 書き込んだことでGCが動作起動されたように見えます。
> 
> おー、なるほど。ってことは、jffs2の制限ですね。
> (GCって書いてしまいましたが、速度の方はGCじゃなくて play-backですね。
> サイズが減るのは GCのおかげです)

元々の話では、sqliteを jffs2上に置いてという話だったと思います。
sqliteにcommit (update?)するときに、かならず open/write/closeのシーケ
ンスで処理されてしまうので、jffs2のようなfs上では他のfsには無い制限が
できてしまいますね。

dbにに限った話ではなく、logのように追記していくものには jffs2には向か
ないようです。もちろん、rotateすれば良いのですが。

	http://lists.infradead.org/pipermail/linux-mtd/2008-January/020386.html

ただ、jffs2はフラッシュメモリという特殊なデバイスを簡単に使えるように
しているので、一概にjffs2が悪いとも言えないと思います。

さて、現実的にはなんとかしなければならないと思うのですが、

 - いつもは、ram上に置いておき、shutdownの前に jffs2に移動する
 - sqliteに commit(update/insert)した後に catを使って移動する

という対応策が考えられると思います。ただ、システムの方までわかっていな
いのでどうすれば良いのかわかっていません。もし良い方法があれば
教えてください。
-- 
           yashi