Thanks for the insight explanation. I did the same test on JFFS2 and the result is much worse than YAFFS2. The first write and erase was a few seconds slower than YAFFS2, but the second one takes up to 6 to 8 minutes, meaning JFFS2 gc is much more complex and slower than YAFFS2.
Ceco
Charles Manning <manningc2@actrix.gen.nz> wrote: On Wednesday 13 September 2006 06:08, goog long wrote:
> I have a test program to create and write many files of the same size. The
> following log shows a test of writing 2000 files of size 100 bytes. I
> repeatly write 2000 files and deleted all the files and do the same again.
> The write time increases any time I repeat the cycle. Is it the behavior
> that we expect? I thought the time should be almost the same. Does it mean
> the writing will be slower if there
are a lot of writing, reading and
> deleting? I am writing a stress test to verify that.
When you delete a file, it is not immediately erased on flash, but is instead
marked as deleted and the actual erasure etc is defered to future garbage
collection operations which happen as part of future write operations (eg.
write, chmod, etc).
Thus, the act of deleting a file is pretty quick but the load for actually
erasing the flash will be spread over subsequent write operations. This has
the effect of slowing down these write operations until the gc is done.
So how much of a slow-down? As is always..... it depends on many factors.
Each write opperation will gc a maximum of one block.
If the flash is pretty full (only a few erased blocks available), then yaffs
will work harder to make new blocks available.
If the flash is not very full, then yaffs will only do gc on blocks which are
very cheap to process.
The
loading of this defered erasing is typically quite low and is pretty much
constant.
The part of gc that is more expensive is when there are are a lot of blocks
with a lot of valid data and just a few garbage chunks (ie. no cheap
options) . This forces yaffs to copy the valid data into new flash before
erasing. Thus, as the flash fills up, yaffs needs to work much harder at gc
and write times can slow down more.
-- Charles
>
> root@omap2430-sdp:/root> flash_eraseall /dev/mtd4
> Erasing 16 Kibyte @ 2b04000 -- 70 % complete.
> Skipping bad block at 0x02b08000
> Erasing 16 Kibyte @ 2bf0000 -- 71 % complete.
> Skipping bad block at 0x02bf4000
> Erasing 16 Kibyte @ 2c54000 -- 72 % complete.
> Skipping bad block at 0x02c58000
> Erasing 16 Kibyte @ 2cdc000 -- 73 % complete.
> Skipping bad block at 0x02ce0000
> Erasing 16 Kibyte @ 3d4c000 -- 99 % complete.
>
root@omap2430-sdp:/root> mount /dev/mtdblock4 /mnt -t yaffs2
> root@omap2430-sdp:/root> time ./small_write 100 2000
>
> real 0m5.150s
> user 0m0.040s
> sys 0m5.110s
> root@omap2430-sdp:/root> rm /mnt/*
> rm: cannot remove `/mnt/lost+found': Is a directory
> root@omap2430-sdp:/root> ls /mnt
> lost+found
> root@omap2430-sdp:/root> time ./small_write 100 2000
>
> real 0m5.160s
> user 0m0.030s
> sys 0m5.130s
> root@omap2430-sdp:/root> rm /mnt/*
> rm: cannot remove `/mnt/lost+found': Is a directory
> root@omap2430-sdp:/root> time ./small_write 100 2000
>
> real 0m5.170s
> user 0m0.060s
> sys 0m5.110s
> root@omap2430-sdp:/root> rm /mnt/*
> rm: cannot remove `/mnt/lost+found': Is a directory
> root@omap2430-sdp:/root> time ./small_write 100 2000
>
> real
0m5.340s
> user 0m0.060s
> sys 0m5.280s
> root@omap2430-sdp:/root> rm /mnt/*
> rm: cannot remove `/mnt/lost+found': Is a directory
> root@omap2430-sdp:/root> time ./small_write 100 2000
>
> real 0m5.550s
> user 0m0.060s
> sys 0m5.490s
>
> Ceco
>
>
> ---------------------------------
> Do you Yahoo!?
> Get on board. You're invited to try the new Yahoo! Mail.
Want to be your own boss? Learn how on Yahoo! Small Business.