mtdblock cache flush at remount

mtdblock cache flush at remount

[Todd Poynor]

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

Re: mtdblock cache flush at remount

[David Woodhouse]

On Wed, 2004-08-18 at 18:10 -0700, Todd Poynor wrote:
> 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. 

Normal filesystems on mtdblock are always going to be horridly
unreliable. If you lose power at the wrong point during the
read/modify/erase/writeback cycle you've lost a _lot_ of data, not just
the sector the file system thought it was writing. 

I don't care much, but if you see a way to make sync() have the desired
effect I wouldn't be averse to it. Criticism in 'diff -u' form always
preferred :)

-- 
dwmw2

Re: mtdblock cache flush at remount

[Todd Poynor]

David Woodhouse wrote:
> I don't care much, but if you see a way to make sync() have the desired
> effect I wouldn't be averse to it.

I took a look, and don't see a good way to fix this short of modifying 
generic code that requires a commit to media (like remount read-only and 
sync).  The modifications might call the block device layer to sync 
things from its standpoint, such as issuing a BLKFLSBUF ioctl.  If 
mtdblock is unique in that it does not necessarily write a block to 
stable storage when the block layer issues a write then this is not 
likely to gain much interest.  It's possible that the IDE drivers might 
want to flush disk hardware buffers in such a situation as well, much 
like what occurs at suspend and shutdown, but I haven't looked into that 
yet.  Thanks,

-- 
Todd Poynor
MontaVista Software

Re: mtdblock cache flush at remount

[David Woodhouse]

On Mon, 2004-09-13 at 18:08 -0700, Todd Poynor wrote:
> If mtdblock is unique in that it does not necessarily write a block to 
> stable storage when the block layer issues a write then this is not 
> likely to gain much interest.  It's possible that the IDE drivers might 
> want to flush disk hardware buffers in such a situation as well, much 
> like what occurs at suspend and shutdown, but I haven't looked into that 
> yet.

IDE and SCSI drives definitely _do_ need precisely this.

-- 
dwmw2