mtdblock caching and syncing

[Doug Graham]

Hello,

I'm running a 2.6.24 kernel, but I've looked over the latest kernel
sources, and I don't see a fix for this (although I could have missed
something).

The problem is that a sync() or fsync() on an mtdblock device does not
actually get the data all the way to the flash device.  The mtdblock
layer maintains its own cache of a single erase-unit (256KB in my case).
If I open /dev/mtdblock0 for writing, write some stuff to it, then call
fsync() but do not close the device, up to one erase-unit's worth of
data may still be buffered in memory.  This data is only flushed when
the device is actually closed (by mtdblock_release).  I think that
this violates the intended semantics of sync and fsync.  I shouldn't be
required to do a close() to force the data to the device.

Another scenario is to open an mtdblock device, write to it, then call
close() without calling fsync().  In this case, the data may not yet be
flushed to the mtdblock layer by the time close() is called, so nothing
gets written to flash during the close().  That's all reasonable so far,
but if I then type "sync" from the shell (or wait for 30 seconds for
pdflush to do its thing), all buffered data *should* be flushed to the
actual device.  As it stands now, the sync will flush data as far as
the mtdblock layer, but that data may then get buffered in the mtdblock
layer forever.  It only gets flushed to the device on a close(), and if
nobody calls close(), it stays there forever.

I think this is fairly serious bug in a flash-based system, where there
are frequently times that you want to make sure that data has actually
made it all the way to the device.  I think that a sync() or fsync()
really ought to somehow propagate all the way down to the mtdblock layer
so that mtdblock can flush its buffer.

Thoughts?  Suggestions?  Patches?

Thanks,
Doug.