On Saturday 16 September 2006 11:48, Wookey wrote:
> On 06-09-15 10:58 -0700, goog long wrote:
> > The log below is for the test of writing 40 MB file. My questions are
> > 1) Why does it take much longer for YAFFS2 to write the same 40 MB
> > file compared to JFFS2?
> > 2) After writing the file, I remove the file and write it again. Why
> > does it take much longer?
> > At the moment, I can only think of one reason. JFFS2 compressed the
> > data before writing to flash, so for
> > 1) JFFS2 writes much less data and it takes less time.
> > 2) After deleting the file, eraseing the flash is deferred to the
> > subsequent writes. Because YAFFS2 data is uncompressed, it takes more
> > time to erase more data.
> That sounds very plausible. I am surprised at the size of the
> difference though. How compressible is the data in this file? How much
> space does it take up on the JFFS2 filesystem and on the YAFFS2
> filesystem? Obvioulsy the more compressible the data, the more the
> test will favour JFFS2.
Yes.
It all depends on the data you are writing.
If you have a very highly compressable test file, then JFFS2 can compress it
to almost nothing. However, with typical data of typical compression levels,
I believe that YAFFS will typically be faster.
If you are making a test file then it is important to use realistic data for
your intended application. It is pointless making a 40MB file full of 0xAA.
Compression varies depending on the fata being managed. Code might typically
compress to 70% or so of original, ASCII text to 40%. MP3 or similar will
hardly compress at all.
>
> Could you repeat the test with a file which is already compressed
> (gzipped, or perhaps a media file)? It would be very interesting to
> see how that affects the results.
>
> (Your comparitive testing is very interesting - do please keep it up,
> and I presume you will report your full results in due course).
>
> It is becoming clear that measuring the performance of these
> filesystems is actually quite a tricky thing to do, and which will
> perform best is highly dependent on the usage scenario.
Yes.
Apart from the compressability aspect, there are other user profile and driver
performance issues that come in to play. For example:
* File size.
* Number of files
* Do you overwrite parts of files (eg. database-like applications)
* Do you just write whole files (eg. media player style applications).
There is no substitute for testing on your own hardware with a test that
matches your typical usage models.
-- Charles
(text/plain)