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

[Artem Bityutskiy <dedekind@infradead.org>]

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.


Yaffs2 is synchronous, so you cannot compare it with UBIFS like this.
Make your test file synchronous then compare. With synchronous file you
will end up with much slower write speed, but sync will not cause sudden
CPU usage peaks, everything will be smoother.

I think opening the file with O_SYNC should do the work. Or chattr +s
should do. Or mount ubifs with -o sync flag to make everything
synchronous, but then everything should become slow as well.

> For example, camera or camcorder application in mobile devices need to write
> the encoded display data steadily to NAND. so because of the high load avg,

The application should be clever enough to be aware of file buffering
and use fsync() after writing some amount of data. Or make the file
synchronous. Or assign lower priority to the camera task.

> so I wanna more light ubi.

It's not about UBI, it is about UBIFS I think, namely about the
buffering. You should be aware of this and be careful with this.

UBIFS fast write speed is not magic. It is because we cache stuff and
postpone writing, which is a well known and nice optimization. In some
situation this may be undesirable, though. So UBIFS is more complex than
yaffs and jffs2 in this respect. The applications which work with UBIFS
should be more clever and the programmers should be aware of stuff like
this:

$ man 2 write:
...
"A  successful return from write() does not make any guarantee that data
has been committed to disk.  In fact, on some buggy implementations, it
does not even guarantee that space has successfully been reserved for
the data.  The only way to be sure is to call fsync(2) after you are
done writing all your data."

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