Quite coincidentally, I've been investigating the very same issue.
I have been able to improve run times somewhat, but still get failures.
Sometimes it will run for over an hour on a PC simulator test harness before
fsx reports an issue. The nandsim+PC is way faster than real NAND so it is
probably equivalent to running on typical ARM + NAND for 4 or 5 hours or so.
What I have now only fails if a mmap write is followed by a truncate down then
truncate up.
I think the problem is probably due to the page dirty flags not being set
correctly resulting in a a read picking up stale data.... or maybe a truncate
not clearing pages properly because a mmap write left some flags in a bad
state.
If I can't get what I have resolved in the next day or so, I'll publish it
somewhere so others can have a look.
-- Charles
On Wednesday 25 November 2009 14:54:45 JiSheng Zhang wrote:
> Hi list,
>
> I come across the same problem in
> http://www.aleph1.co.uk/lurker/message/20071008.015825.d64e796b.pt.html
>
> But If I don't use mmap write, fsx will succeed all the time. This is
> different from the email thread above.
>
> I also add
>
> if (ivalid & ATTR_SIZE && inode->i_size > attr->ia_size)
> vmtruncate(inode, attr->ia_size);
>
> in yaffs_setattr(), result is the same.
> IMHO inode_setattr() in yaffs_setattr() will call vmtruncate()
>
> Any advice for resolve this bug?
>
> Thanks,
> Jisheng
>
> _______________________________________________
> yaffs mailing list
> yaffs@lists.aleph1.co.uk
> http://lists.aleph1.co.uk/cgi-bin/mailman/listinfo/yaffs
(text/plain)