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

[Artem Bityutskiy <dedekind@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.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)