static vs. dynamic UBI volume

static vs. dynamic UBI volume

[twebb]

Can a UBI volume be declared vol_type=static, but mounted with "ro"?
Conversely, if a volume is declared vol_type=dynamic, is it acceptable
to mount "ro" or "rw"?  I'm trying to understand if there are
dependencies between the two.

I'm seeing a very occasional problem on a volume that is
vol_type=dynamic, and is mounted "rw" during startup, then finally
"ro".  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
[   12.897619] UBIFS error (pid 1): ubifs_scan: corrupt empty space at
LEB 2:268135
[   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


Not sure if this is corruption within NAND or something else.

twebb

Re: static vs. dynamic UBI volume

[Artem Bityutskiy]

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 (Артём Битюцкий)