[PATCH] Fix hanging close for /dev/mtd
joern at logfs.org
Wed Jun 13 10:29:26 EDT 2007
[ Putting David on Cc:. This is a bug report for JFFS2 ]
On Wed, 13 June 2007 15:29:38 +0200, Joakim Tjernlund wrote:
> On Wed, 2007-06-13 at 13:54 +0200, Jörn Engel wrote:
> > In this case you made me wonder. What is the mtd->sync method supposed
> > to accomplish anyway? mtd->write is synchronous, mtd->erase de-facto
> > also is. So it cannot be a sync in the sense of "flush all dirty data
> > to flash and don't return before you're finished". Or can it?
> Yes, this is also my view(for NOR flash, NAND is diffrent).
> mtd->erase can be suspended though, but it doesn't matter
> in this case. However, I don't know enough to be 100% sure
At the very least that method needs better documentation than:
/* Sync */
void (*sync) (struct mtd_info *mtd);
I can see two sane alternatives.
* An MTD driver may return from mtd->write() calls before the data has
* safely been written to the medium. Any amount of dirty data may be
* cached by either the driver or the device. If a filesystem depends
* on the data being safely on the medium, it has to explicitly call
* Mtd->write() and mtd->erase() methods may only return if the data has
* been safely written to the device. Special care needs to be taken
* for devices that support caching.
My tendency is to favor the first variant. Block2mtd already implements
it. And if we went for variant two, mtd->sync() would be pointless and
should get removed.
Now to the bug report:
JFFS2 must call mtd->sync() for its various sync routines. If mounted
with -o sync or for files opened with O_SYNC, it has to call that after
every write. If nothing else, it is currently broken on block2mtd.
Linux [...] existed just for discussion between people who wanted
to show off how geeky they were.
-- Rob Enderle
More information about the linux-mtd