[PATCH] Fix hanging close for /dev/mtd

[Joakim Tjernlund]

On Wed, 2007-06-13 at 16:29 +0200, Jörn Engel wrote:
> [ 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->sync().
>  */
> 
> /*
>  * 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. 

   Me too.

>  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.

Sure, but for NOR flash this sync can be a NOP, right?

 Jocke