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
(text/plain)