JFFS2 as transactional FS (in other words: how to be sure that data have been writtent correctly from userspace)

Jörn Engel joern at lazybastard.org
Thu Mar 8 09:43:52 EST 2007

On Thu, 8 March 2007 08:35:17 -0600, Josh Boyer wrote:
> On Thu, 2007-03-08 at 13:58 +0000, David Woodhouse wrote:
> > On Thu, 2007-03-08 at 07:44 -0600, Josh Boyer wrote:
> > > Wait... why?  Rejecting mount -o sync seems sane, but why can't O_SYNC
> > > support be handled?  If users want to open their files like that and it
> > > causes JFFS2 to flush a bunch of padding out, well they asked for it. 
> > 
> > Users ask for shared writable mmap too. That isn't a good idea either.
> > 
> > Contemplate what Linus always says about using 'volatile' vs. proper
> > barriers. Now consider it for O_SYNC vs. fsync(). And factor in the fact
> > that O_SYNC is going to be massively suboptimal if it causes syncs when
> > they otherwise didn't need to happen.
> Ok, good point.  You've convinced me.

I can imagine cases when O_SYNC makes sense.  Logfiles, basically.
When debugging it is useful to have as much information in them as
possible, especially right before the crash.  O_SYNC is a useful
relaxation here on system where fsync() is identical to sync() - O_SYNC
will not flush every other file in the system.

Whether any applications actually do this is anyone's guess, though.


Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface.
-- Doug MacIlroy

More information about the linux-mtd mailing list