From: Dmitry Bazhenov <atrey@emcraft.com>
To: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 node versioning problem?
Date: Wed, 3 May 2006 18:28:51 +0400 [thread overview]
Message-ID: <200605031828.51552.atrey@emcraft.com> (raw)
In-Reply-To: <44589BCE.2060402@yandex.ru>
On Wednesday 03 May 2006 16:02, Artem B. Bityutskiy wrote:
> Can it happen with a real-life flash device? If it can, we have to
> switch to 64-bit versions.
I think it can happen. I can imagine at least one scenario where such
situation can occur. Of course, in normal circumstances it is hardly possible
but in the case of a powerfail it can be.
1. Assume, upon a call to jffs2_commit_write() function the
f->highest_version has the maximum value.
2. jffs2_commit_write() increments f->highest_version which becomes 0.
3. jffs2_commit_write() invokes jffs2_write_dnode() with version=0.
5. Powerfail before obsoleting least recent overlapping nodes.
6. After reset, the scan process finds two(if were only one node for the
commited page before) valid nodes wich refer to the same region. It places
the least recent node which has the maximum version number at the end of
the node list.
7. When jffs2_read_inode() function is invoked, the node with the biggest
version number is added last, thus, obsoleting all overlapping nodes.
The most recent inode is obsoleted as well. --> Bug.
As a workaround I suggest to obsolete previous nodes before writing the new
one. In case of powerfail there will be holes in data which can be easily
recognized during inode reading.
--
Regards,
Dmitry
next prev parent reply other threads:[~2006-05-03 14:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-03 11:56 JFFS2 node versioning problem? Dmitry Bazhenov
2006-05-03 12:02 ` Artem B. Bityutskiy
2006-05-03 14:28 ` Dmitry Bazhenov [this message]
2006-05-03 14:35 ` Dmitry Bazhenov
2006-05-03 14:42 ` Artem B. Bityutskiy
2006-05-03 14:40 ` Artem B. Bityutskiy
2006-05-03 15:07 ` Dmitry Bazhenov
2006-05-03 15:07 ` Josh Boyer
2006-05-03 15:11 ` Josh Boyer
2006-05-03 15:21 ` Jörn Engel
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=200605031828.51552.atrey@emcraft.com \
--to=atrey@emcraft.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox