ubifs, ubiblk(formatted with vfat) and yaffs2 test.

[KeunO Park]

2008/5/30, Artem Bityutskiy <dedekind at infradead.org>:
> On Fri, 2008-05-30 at 15:02 +0300, Artem Bityutskiy wrote:
> > On Fri, 2008-05-30 at 16:15 +0900, KeunO Park wrote:
> > > > Yes, yaffs, jffs2 are "special" class of file-systems and they were not
> > > > designed to be what you call "mass storage class func". They should
> > > > rather be used as root file system on "internal" flash, which is smaller
> > > > than "mass memory", where you store your core libraries, etc.
> > > >
> > > >> yaffs2
> > > >> write: 10.20s, 12.09s, 12.24s avg:11.51s (868KB/s)
> > > >> load avg right after copy&sync: 0.03 -> 0.11
> > > >>
> > > >> ubifs (LZO)
> > > >> write: 14.45s, 14.40s, 14.45s avg:14.43s (693KB/s)
> > > >> load avg right after copy&sync: 0.03 -> 0.53
> > > >>
> > > >> ubifs (ZLIB)
> > > >> write : 27.17s, 27.18s, 27.21s avg:27.18 (367KB/s)
> > > >> load avg right after copy&sync: 0.03 -> 0.80
> > > >>
> > > >> ubifs (No Compression)
> > > >> write: 6.69s, 10.90s, 10.98s avg:9.52s (1050KB/s)
> > > >> load avg right after copy&sync: 0.03 -> 0.43
> > > > We beat yaffs2? Sounds nice :-)
> > >
> > > according to the above result(and only with no compressor option :-), yes.
> > > but, I think that load avg result is too much higher than yaffs2's.
> >
> > So what you do is you write a large file, this does not go to the flash
> > but instead sits in the kernel buffers, in the page cache, then you call
> > fsync() which causes _massive_ page-cache write-back (flushing) and
> > consume a lot of CPU.
>
> But I have to add that of course, YAFFS/JFFS2 are more light-weight
> file-system, because they do not maintain the FS index on the flash
> media. UBIFS does and this costs extra CPU cycles and extra I/O.
>

actually I did write & fsync the file during test. :-)
anyway thank you for your comment.

regards,
KeunO Park.