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

[Jörn Engel]

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.

Jörn

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