JFFS2 determine writing state
Jamie Lokier
jamie at shareable.org
Tue Jan 15 09:08:00 EST 2008
Josh Boyer wrote:
> On Sat, 12 Jan 2008 10:03:43 +0000 Jamie Lokier <jamie at 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
More information about the linux-mtd
mailing list