It will depend very much on the types of application you're running.

If your test is creating, renaming and deleting a lot, relative to other 
operations then you will see the mtime change cause a lot more traffic since 
a new directory record is being written on every cretion, rename  or 
deletion.


If, however, your typical application tends to write fewer larger files (ie. 
mostly, say,  50k+) or update existing files then the effect will be diluted.

From what I have seen, postmark tries to simulate a large mail server (lots of 
small files) so this would be close to worst case scenario for yaffs.

If this is a big issue I guess some heuristics could be applied to delay 
writing the directories for mtimes. That way application like postmark would 
update the directory records less often.

-- CHarles




On Tuesday 02 June 2009 15:23:26 Karl wrote:
> Hi,
>
> I run postmark on two versions of yaffs2, one with mtime update and one
> without, with a modified nandsim, which records how many read/write/erase
> during the test. The result shows that with the mtime update enabled,
> yaffs2 needs about 30% more read/write/erase I/O in postmark.
>
> In yaffs without mtime update(more clearly, with yaffs_fs.c v1.80 in the
> cvs repository, and yaffs_guts.c v1.82) the read/write/erase counting
> result is:
>
> Read0 195328 ReadOOB 178371 Write0 357501 WriteOOB 0 Erase 3663
>
> In yaffs with mtime update(yaffs_fs.c v1.81 and yaffs_guts.c v1.84), the
> counting result is:
>
> Read0 288958 ReadOOB 178371 Write0 451131 WriteOOB 0 Erase 5047
>
> Well, I have have no idea whether this will cause efficiency problems in
> realworld applications.
>
> Here are the commands I run in postmark, with a 256MB MTD partition:
>
> set number 10000
> set transactions 50000
> set subdirectories 1000
> set buffering false
> set seed 2
> run
>
> Karl
> 2009.6.2
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs