All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Artem Bityutskiy <dedekind@infradead.org>
Cc: "Vellemans, Noel" <Noel.Vellemans@visionBMS.com>,
	linux-mtd@lists.infradead.org
Subject: Re: JFFS2 powerfail ?
Date: Wed, 23 Apr 2008 18:48:58 +0100	[thread overview]
Message-ID: <20080423174858.GA12903@shareable.org> (raw)
In-Reply-To: <1208964812.11721.81.camel@sauron>

Artem Bityutskiy wrote:
> > JFFS2 notice: (791) check_node_data: wrong data CRC in data node at 0x01062120: read 0xfac2f85a, calculated 0x9ac0c6d1.
> > JFFS2 notice: (791) check_node_data: wrong data CRC in data node at 0x002b9bf0: read 0x9f182fab, calculated 0x4ad20e5f.
> > JFFS2 notice: (791) check_node_data: wrong data CRC in data node at 0x002b5d60: read 0x79a2a9d8, calculated 0x35234c9a.
> 
> This is normal. It's just half-written nodes which correspond to the
> last writes you made before the power cut. They are harmless, although
> spam the syslog. JFFS2 cannot remove them straight after mount, so they
> may accumulate. Which means each time you see corruption messages for
> the previous unclean reboots. However, the corrupted nodes will go away
> some time, when JFFS2 decides to garbage-collect corresponding
> eraseblocks. IOW, don't worry, this is a feature.

If they are going to be removed at the next GC, it would be nice to
remove them earlier by overwriting them with all-1s - would that work?

I'm thinking of the case where device spews a page of CRC errors on
every boot for a long time, until you until you write enough data to
the filesystem that it reclaims these blocks - which you might not do
for a long time (if ever).

(Alternatively, can triggering a background GC clean them up reliably?)

After all, there might be application level recovery for partially
written files, but that won't clean up the incomplete nodes.

-- Jamie

  reply	other threads:[~2008-04-23 17:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-23 15:26 JFFS2 powerfail ? Vellemans, Noel
2008-04-23 15:33 ` Artem Bityutskiy
2008-04-23 17:48   ` Jamie Lokier [this message]
2008-04-23 17:52     ` Artem Bityutskiy
2008-04-24  6:03       ` Ram

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=20080423174858.GA12903@shareable.org \
    --to=jamie@shareable.org \
    --cc=Noel.Vellemans@visionBMS.com \
    --cc=dedekind@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.