Re: JFFS2 determine writing state

[Jamie Lokier <jamie@shareable.org>]

Josh Boyer wrote:
> On Sat, 12 Jan 2008 10:03:43 +0000 Jamie Lokier <jamie@shareable.org> wrote:
> 
> > Josh Boyer wrote:
> > > The open call doesn't cause any writes, and close
> > > is supposed to flush all pending writes before it returns.
> > 
> > Oh, that's interesting.  So on JFFS2, fsync() is unnecessary
> > before close()?
> > 
> > (On other filesystems it's necessary, of course).
> 
> To be honest, it doesn't really matter if it's necessary or not.
> Writing an application to do as little as possible based on implicit
> knowledge of the underlying filesystem seems like a really bad idea.
> Particularly with the behavior of the filesystem can change based on
> which config options you have set (writebuffer, etc).
> 
> Write you applications to be portable and cautious and you shouldn't
> have a problem.

That's quite reasonable and of course I do call fsync, both on a file
before closing it, and then on its parent directory after renaming a
replacement file into place (just like usual mail software).

But the particular fs behaviour is relevant the other way around: I
have a program which calls open/write/close with small writes
moderately often (because it calls another program which actually
operates on the file).

If JFFS2 commits pending writes on every close, I should change things
to keep the file open between writes so they are coalesced and faster,
when I don't need the individual writes to be committed separately.
When I do need the data committed I can use fsync of course.

In which case, if a program A opens a file on JFFS2, and forks/execs
program B which writes data, then does an implicit close (when it
exits), while B's writes be committed immediately (which isn't wanted)
even though A still has the descriptor open?

Thanks,
-- Jamie