mtdblock cache flush at remount

[Todd Poynor <tpoynor@mvista.com>]

So far as I've been able to determine, the mtdblock cache is not 
automatically flushed after a remount read-only, including remounts 
performed by a sysrq-s emergency sync.

To pick the somewhat silly example of an ext3 filesystem, the "no 
recovery needed" superblock modification of which still sits in the 
cache after the remount:

# mount -o remount -o ro /mnt/mtd
# dumpe2fs /dev/mtd2
...
Filesystem features:      has_journal filetype needs_recovery sparse_super
...
# # Block access shows the modified value, and the mount/unmount
# # flushes the value to flash.
# dumpe2fs /dev/mtdblock2
...
Filesystem features:      has_journal filetype sparse_super
...
# dumpe2fs /dev/mtd2
...
Filesystem features:      has_journal filetype sparse_super

Since the block is committed from the block layer's point of view, even 
a following sync won't flush it out; it seems only something like an 
unmount (which explicitly calls the block device layer to release the 
superblock) will flush it.  In certain admittedly unusual situations 
this is undesirable (in particular, consumer electronics device flushing 
and marking clean filesystems prior to a prolonged system suspend 
interval during which it is expected batteries may die or be changed).

Figured I'd check whether anybody feels this is something that could and 
should be fixed or whether there's already a solution for this.  I've 
recommended use of only mtd-savvy filesystems like JFFS2 for this sort 
of usage, but the CE developers I talked to felt filesystems over 
mtdblock were also important.  Thanks,

-- 
Todd Poynor
MontaVista Software