Powerfail-tests and jffs2-sync-mount

Artem Bityutskiy dedekind at infradead.org
Fri Mar 7 03:09:36 EST 2008


On Fri, 2008-03-07 at 08:45 +0100, Schlaegl Manfred jun. wrote:
> > > Now my question: Are there any non-obvious disadvantages, mounting jffs2
> > > synchronal, except lower speed and a little(depends on usage) decreased
> > > flash-life-time (wear-out), or is this anyway the default approach?
> > 
> > My understanding of the things is that this should not really matter. I
> > thought if you have some corruption in asynchronous mode, you should
> > have them in synchronous too, may its worth trying more synchronous mode
> > testing?
> > 
> I thought it's a matter of file-buffers between the file-operations and
> jffs2, but these buffer should be flushed on close of the file, so there
> should be no problem with echo.
> I think i've to take a look on vfs, perhaps there is some buffering, or
> (even worst) some reodering of actions.

Actually JFFS2 is synchronous from VFS's point of view. It does not have
write back for pages and inodes, and every time VFS asks to write
something, JFFS2 just writes straight away, without any postponing.

But, JFFS2 has its small internal buffer. Design-wise, it sits somewhere
at the bottom level of JFFS2, just before the I/O level.

The buffer (so-called write-buffrer) has size equivalent to NAND page
size. I think it is 2048 bytes in your case. All writes go to this
buffer, and when it becomes full, it is flushed to the flash. This is a
optimization which makes sure JFFS2 does not waste too much space,
because without the buffer it would waste space up to the next NAND page
on each write.

Thus, when you mount the FS with -a sync, it should flush the write
buffer every time before returning to user-space.

So, basically, returning to your original question - there should not be
too much difference, but I'd expect synchronous mode to be slower. E.g.,
compare:

time dd if=/dev/zero of=file
time tar -xf many_small_files_inside.tar

on sync and async mounts.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)




More information about the linux-mtd mailing list