public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: "Schlaegl Manfred jun." <manfred.schlaegl@gmx.at>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Powerfail-tests and jffs2-sync-mount
Date: Fri, 07 Mar 2008 10:09:36 +0200	[thread overview]
Message-ID: <1204877376.23706.73.camel@sauron> (raw)
In-Reply-To: <1204875955.3476.13.camel@lisa.alm.archives.at>


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 (Битюцкий Артём)

  reply	other threads:[~2008-03-07  8:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-06 16:41 Powerfail-tests and jffs2-sync-mount Schlägl Manfred jun.
2008-03-07  6:10 ` Artem Bityutskiy
2008-03-07  7:45   ` Schlaegl Manfred jun.
2008-03-07  8:09     ` Artem Bityutskiy [this message]
2008-03-25  6:50       ` Schlaegl Manfred jun.

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1204877376.23706.73.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=manfred.schlaegl@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox