mtdblock cache flush at remount
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,
Signature · 2 lines
Todd Poynor MontaVista Software
Quoted 5 lines · Todd Poynor
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 :)
Signature · 1 line
dwmw2
Quoted 2 lines · David Woodhouse
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,
Signature · 2 lines
Todd Poynor MontaVista Software
Quoted 6 lines · Todd Poynor
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.
Signature · 1 line
dwmw2