Re: mmap returns incorrect data

[marcus hall <marcus@tuells.org>]

On Thu Apr 29 2004 - 18:48:22 EST, Russell King wrote:
>You _really_ don't want to use ext3 on CF unless you want to wear the
>flash quickly. Just because a filesystem has journaling does _not_
>mean that its suitable for flash (in fact, it may be far worse for
>flash than its non-journaled counterpart, as in this case.)

I was concerned about that in the beginning, and was told that CF devices
perform wear-leveling internally.  In fact, we have had units in the field
for a couple of years without failure, so my objections carried little
weight.  In practice, the filesystem isn't often written.  Since the jffs2
filesystem seems to be intertwined with the mtd drivers, there don't seem
to be any other good failure-tolerant solutions.  But, that isn't the
point for now..

>This is an IDE driver bug - it performs PIO but does not ensure that the
>individual pages are properly flushed to RAM before telling the kernel
>that the IO is complete. (If someone wants to disagree, look at how
>rd.c does flush_dcache_page, and see previous discussions on lkml
>concerning this.)

Yes, this was in fact where the problem was.  In the 2.5.59 kernel, in
mm/filemap.c there were still two calls to flush_page_to_ram(), but in
include/asm-arm/proc-armv/cache.h this was defined to be a nop.  I
replaced the flush_page_to_ram() calls with flush_dcache_page() calls
and everything started working properly.

In later versions, the flush_page_to_ram() calls have been removed from
filemap.c, and I do not see any replacement of the functionality (at least
nothing that seems clear to me!)

I would like to eventually move forward to a 2.6 kernel, so I am interested
in how this is addressed there.

I also didn't seem to find (or recognize) the earlier discussion, so perhaps
it is covered there..

Anyhow, thanks for the help.  Things are rolling again!

Marcus Hall
marcus@tuells.org