* Re: static vs. dynamic UBI volume
2010-01-19 14:41 static vs. dynamic UBI volume twebb
@ 2010-02-02 6:20 ` Artem Bityutskiy
0 siblings, 0 replies; 2+ messages in thread
From: Artem Bityutskiy @ 2010-02-02 6:20 UTC (permalink / raw)
To: twebb; +Cc: linux-mtd
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 (Артём Битюцкий)
^ permalink raw reply [flat|nested] 2+ messages in thread