From: Artem Bityutskiy <dedekind@infradead.org>
To: Eric Holmberg <Eric_Holmberg@Trimble.com>
Cc: Urs Muff <urs_muff@Trimble.com>,
linux-mtd@lists.infradead.org, Stefan Roese <sr@denx.de>,
Jamie Lokier <jamie@shareable.org>,
Adrian Hunter <adrian.hunter@nokia.com>
Subject: RE: UBIFS Corrupt during power failure
Date: Mon, 25 May 2009 15:57:06 +0300 [thread overview]
Message-ID: <1243256226.21646.116.camel@localhost.localdomain> (raw)
In-Reply-To: <1243256082.21646.114.camel@localhost.localdomain>
On Mon, 2009-05-25 at 15:54 +0300, Artem Bityutskiy wrote:
> On Mon, 2009-05-25 at 11:38 +0300, Artem Bityutskiy wrote:
> > Presumably what happens it: UBIFS scans LEB 120. It checks the first
> > node, and finds CRC mismatch. Then UBIFS logic is as follows. If this
> > corrupted node is the last one, then there was a write interrupt,
> > which is harmless. But if after this node some other data follows,
> > this is some serious corruption. So the 'is_last_write()' function
> > is called, it is supposed to check that.
> >
> > In 'is_last_write()' I see it has different logic depending on whether
> > c->min_io_size == 1 or not. The former case is NOR case, the latter
> > is NAND. Well, since I know we never tested UBIFS well for NOR,
> > I conclude the NOR case may have a bug.
>
> Oh, this 'c->min_io_size == 1' case is just dead code, we never have
> c->min_io_size < 8 in UBIFS. So I just remove that (patch at the end
> of the e-mail).
>
> Eric, please, reproduce this problem again. Then please, do not
> "fix" it from u-boot. But instead, please do:
>
> 1. Enable UBIFS debugging
> 2. Enable recovery and mount messages, by booting with
> "ubifs.debug_msgs=6144" kernel parameter
> 3. also add the "ignore_loglevel" boot parameter
> 4. capture _all_ messages in minicom
> 5. If possible, make a full dump of your flash to play with it
> later.
>
> Share the messages with us. I hope we can fix these problems.
> Just provide us the info.
Err, and the patch.
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Subject: [PATCH] UBIFS: remove dead code
UBIFS assumes that @c->min_io_size is 8 in case of NOR flash. This
is because UBIFS alignes all nodes to 8-byte boundary, and maintaining
@c->min_io_size introduced unnecessary complications.
This patch removes senseless constructs like:
if (c->min_io_size == 1)
NOR-specific code
Also, few commentaries amendments.
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
---
fs/ubifs/budget.c | 1 -
fs/ubifs/recovery.c | 31 ++++---------------------------
2 files changed, 4 insertions(+), 28 deletions(-)
diff --git a/fs/ubifs/budget.c b/fs/ubifs/budget.c
index d0231ba..eaf6d89 100644
--- a/fs/ubifs/budget.c
+++ b/fs/ubifs/budget.c
@@ -91,7 +91,6 @@ static int shrink_liability(struct ubifs_info *c, int nr_to_write)
return nr_written;
}
-
/**
* run_gc - run garbage collector.
* @c: UBIFS file-system description object
diff --git a/fs/ubifs/recovery.c b/fs/ubifs/recovery.c
index 1066297..8056052 100644
--- a/fs/ubifs/recovery.c
+++ b/fs/ubifs/recovery.c
@@ -343,33 +343,15 @@ int ubifs_write_rcvrd_mst_node(struct ubifs_info *c)
*
* This function returns %1 if @offs was in the last write to the LEB whose data
* is in @buf, otherwise %0 is returned. The determination is made by checking
- * for subsequent empty space starting from the next min_io_size boundary (or a
- * bit less than the common header size if min_io_size is one).
+ * for subsequent empty space starting from the next @c->min_io_size boundary.
*/
static int is_last_write(const struct ubifs_info *c, void *buf, int offs)
{
- int empty_offs;
- int check_len;
+ int empty_offs, check_len;
uint8_t *p;
- if (c->min_io_size == 1) {
- check_len = c->leb_size - offs;
- p = buf + check_len;
- for (; check_len > 0; check_len--)
- if (*--p != 0xff)
- break;
- /*
- * 'check_len' is the size of the corruption which cannot be
- * more than the size of 1 node if it was caused by an unclean
- * unmount.
- */
- if (check_len > UBIFS_MAX_NODE_SZ)
- return 0;
- return 1;
- }
-
/*
- * Round up to the next c->min_io_size boundary i.e. 'offs' is in the
+ * Round up to the next @c->min_io_size boundary i.e. @offs is in the
* last wbuf written. After that should be empty space.
*/
empty_offs = ALIGN(offs + 1, c->min_io_size);
@@ -392,7 +374,7 @@ static int is_last_write(const struct ubifs_info *c, void *buf, int offs)
*
* This function pads up to the next min_io_size boundary (if there is one) and
* sets empty space to all 0xff. @buf, @offs and @len are updated to the next
- * min_io_size boundary (if there is one).
+ * @c->min_io_size boundary.
*/
static void clean_buf(const struct ubifs_info *c, void **buf, int lnum,
int *offs, int *len)
@@ -402,11 +384,6 @@ static void clean_buf(const struct ubifs_info *c, void **buf, int lnum,
lnum = lnum;
dbg_rcvry("cleaning corruption at %d:%d", lnum, *offs);
- if (c->min_io_size == 1) {
- memset(*buf, 0xff, c->leb_size - *offs);
- return;
- }
-
ubifs_assert(!(*offs & 7));
empty_offs = ALIGN(*offs, c->min_io_size);
pad_len = empty_offs - *offs;
--
1.6.0.6
--
Best regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2009-05-25 12:57 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 13:45 UBIFS Corrupt during power failure Eric Holmberg
2009-03-24 15:30 ` Adrian Hunter
2009-03-24 17:04 ` Eric Holmberg
2009-03-24 18:16 ` Eric Holmberg
2009-03-25 6:32 ` Artem Bityutskiy
2009-03-26 6:59 ` Artem Bityutskiy
2009-03-26 14:09 ` Eric Holmberg
2009-03-30 19:00 ` Eric Holmberg
2009-03-31 14:45 ` Artem Bityutskiy
2009-04-10 12:25 ` Artem Bityutskiy
2009-04-10 14:27 ` Eric Holmberg
2009-04-10 15:17 ` Artem Bityutskiy
2009-04-10 15:49 ` Artem Bityutskiy
2009-04-10 17:00 ` Eric Holmberg
2009-04-10 17:11 ` Artem Bityutskiy
2009-04-10 18:33 ` Eric Holmberg
2009-04-14 6:11 ` Artem Bityutskiy
2009-04-14 15:09 ` Eric Holmberg
2009-04-14 15:45 ` Artem Bityutskiy
2009-04-14 15:53 ` Artem Bityutskiy
2009-04-14 18:00 ` Jamie Lokier
2009-04-15 6:00 ` Artem Bityutskiy
2009-04-15 15:17 ` Eric Holmberg
2009-04-15 16:09 ` Jamie Lokier
2009-04-15 16:12 ` Artem Bityutskiy
2009-04-15 16:32 ` Eric Holmberg
2009-04-15 16:44 ` Jamie Lokier
2009-04-15 18:26 ` Nicolas Pitre
2009-04-15 18:38 ` Jamie Lokier
2009-04-15 19:33 ` Eric Holmberg
2009-04-15 20:15 ` Nicolas Pitre
2009-04-15 20:46 ` Jamie Lokier
2009-04-16 5:51 ` Artem Bityutskiy
2009-04-16 5:46 ` Artem Bityutskiy
2009-04-16 21:34 ` Jamie Lokier
2009-04-17 8:56 ` Artem Bityutskiy
2009-04-17 13:51 ` Jamie Lokier
2009-04-17 14:36 ` Artem Bityutskiy
2009-04-17 23:49 ` Eric Holmberg
2009-05-15 7:16 ` Stefan Roese
2009-05-18 17:30 ` Eric Holmberg
2009-05-19 8:18 ` Artem Bityutskiy
2009-05-19 22:16 ` Eric Holmberg
2009-05-25 8:38 ` Artem Bityutskiy
2009-05-25 12:54 ` Artem Bityutskiy
2009-05-25 12:57 ` Artem Bityutskiy [this message]
2009-07-03 13:26 ` Artem Bityutskiy
2009-07-03 13:29 ` Artem Bityutskiy
2009-07-03 13:33 ` Urs Muff
2009-07-03 14:05 ` Artem Bityutskiy
2009-07-03 14:47 ` Urs Muff
2009-07-03 14:58 ` Artem Bityutskiy
2009-07-06 4:30 ` Artem Bityutskiy
2009-07-06 4:51 ` Artem Bityutskiy
2009-07-06 6:43 ` Artem Bityutskiy
2009-07-07 6:46 ` Artem Bityutskiy
2009-07-07 7:05 ` Urs Muff
2009-07-13 18:22 ` Eric Holmberg
2009-07-14 5:34 ` Artem Bityutskiy
2009-07-15 20:52 ` Jamie Lokier
2009-07-15 21:35 ` Eric Holmberg
2009-07-16 7:33 ` Artem Bityutskiy
2009-07-24 6:49 ` Artem Bityutskiy
2009-07-24 12:00 ` Artem Bityutskiy
2009-07-24 13:39 ` Eric Holmberg
2009-07-24 14:55 ` Artem Bityutskiy
2009-07-24 14:05 ` Jamie Lokier
2009-07-24 14:09 ` Artem Bityutskiy
2009-07-16 7:09 ` Artem Bityutskiy
2009-07-16 16:49 ` Jamie Lokier
2009-07-17 7:07 ` Artem Bityutskiy
2009-07-15 20:55 ` Jamie Lokier
2009-07-15 21:36 ` Eric Holmberg
2009-07-15 22:09 ` Jamie Lokier
2009-07-16 7:22 ` Artem Bityutskiy
2009-07-16 7:16 ` Artem Bityutskiy
2009-07-16 20:54 ` Gilles Casse
2009-07-17 0:29 ` Carl-Daniel Hailfinger
2009-07-24 14:08 ` Jamie Lokier
2009-07-16 7:14 ` Artem Bityutskiy
2009-06-03 8:08 ` Artem Bityutskiy
2009-06-03 8:25 ` Stefan Roese
2009-06-03 13:50 ` Eric Holmberg
2009-06-07 10:16 ` Artem Bityutskiy
2009-07-28 12:01 ` news
2009-07-28 12:24 ` Adrian Hunter
2009-07-28 17:19 ` Eric Holmberg
2009-08-09 4:59 ` Artem Bityutskiy
2009-04-17 8:58 ` Artem Bityutskiy
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=1243256226.21646.116.camel@localhost.localdomain \
--to=dedekind@infradead.org \
--cc=Eric_Holmberg@Trimble.com \
--cc=adrian.hunter@nokia.com \
--cc=jamie@shareable.org \
--cc=linux-mtd@lists.infradead.org \
--cc=sr@denx.de \
--cc=urs_muff@Trimble.com \
/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