From: Artem Bityutskiy <dedekind1@gmail.com>
To: twebb <taliaferro62@gmail.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: static vs. dynamic UBI volume
Date: Tue, 02 Feb 2010 08:20:37 +0200 [thread overview]
Message-ID: <1265091637.2517.30.camel@localhost.localdomain> (raw)
In-Reply-To: <dbdb2ea61001190641l14a0603kfe9b45f52576da60@mail.gmail.com>
On Tue, 2010-01-19 at 09:41 -0500, twebb wrote:
> Can a UBI volume be declared vol_type=static, but mounted with "ro"?
Yes. Static volumes are not writable, so this is the only way they can
be mounted.
> Conversely, if a volume is declared vol_type=dynamic, is it acceptable
> to mount "ro" or "rw"?
Yes. Dynamic volumes are writable, so you can choose R/O or R/W.
> I'm seeing a very occasional problem on a volume that is
> vol_type=dynamic, and is mounted "rw" during startup, then finally
> "ro".
If UBIFS switches to R/O mode, this means there is some problem, e.g.,
there are unexpected corruptions, etc. Switching to R/O mode is a
defensive measure.
> The ubiattach works fine, but when trying to initially mount
> (as "rw"), I've seen...
>
> [ 12.887251] UBI error: ubi_io_read: error -74 while reading 516096
> bytes from PEB 4:8192, read 516096 bytes
-74 is -EBADMSG. It is returned by the MTD driver and should mean that
the driver found an unrecoverable ECC error.
UBIFS is reading whole LEB. MTD returns -EBADMSG. So somewhere in these
516096 bytes of data an unrecoverable ECC error happened.
But UBIFS does not give up. It's logic is that "I have everything
protected by CRC32, if there are problems, I'll detect them". So UBIFS
continues.
> [ 12.897619] UBIFS error (pid 1): ubifs_scan: corrupt empty space at
> LEB 2:268135
So UBIFS continues. I probably finds valid nodes, or may be not. Anyway,
UBIFS sees that 0xFF bytes, and concludes the rest of the LEB should
contain only 0xFFs, i.e., empty space.
However, at offset 268135 UBIFS findes non-0xFFs, which is invalid.
If you followed my instructions here:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_how_send_bugreport
You would have hexdump of the data and we could see what is in the
buffer. It could help.
> [ 12.905060] UBIFS error (pid 1): ubifs_scanned_corruption:
> corruption at LEB 2:268135
> [ 12.922940] UBIFS error (pid 1): ubifs_scan: LEB 2 scanning failed
> [ 13.048269] UBI error: ubi_io_read: error -74 while reading 516096
> bytes from PEB 4:8192, read 516096 bytes
> [ 13.058549] UBIFS error (pid 1): ubifs_recover_master_node: failed
> to recover master node
And UBIFS does not know how to proceed with that.
> Not sure if this is corruption within NAND or something else.
May be something specific to MLC. May be a bug in the NAND driver. May
be a bug in UBIFS. May be you made some mistake at some point, dunno.
Is this reproducible?
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
prev parent reply other threads:[~2010-02-02 6:20 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 14:41 static vs. dynamic UBI volume twebb
2010-02-02 6:20 ` Artem Bityutskiy [this message]
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=1265091637.2517.30.camel@localhost.localdomain \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=taliaferro62@gmail.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