I need help analyzing a failed UBIfs

[Artem Bityutskiy]

Hi,

On Mon, 2012-01-02 at 14:11 -0500, Atlant Schmidt wrote:
>     o Is the failed LEB part of the UBIfs "Wandering
>       Journal" or is it storing actual, fully-committed
>       parts of the data volume such as iNodes, directories,
>       or file data extents?*

To get the list of uncommitted journal LEBs you have to analyze the Log
which is stored at the beginning of the volume and has a fixed address.

>   Looking at a data dump of the volume (from the MTD
>   level), is there an easy way to determine this?
>   For example, "All the Journal LEBs are listed in
>   a table at..."**

I think in case of error UBIFS prints a lot of information, if debugging
is enabled. It uses KERN_DEBUG level, though, which causes a lot of
confusion because people do not realize that they have a lot of info, it
is just not in their console and they have to type 'dmesg'. A patch
which changes this would be welcome.

Anyway, the info you want can be printed there as well.

>  * I'm assuming that LEBs are either fully-allocated to
>    the Wandering Journal or fully-available to the "data
>    volume"; if this assumption is incorrect, I'm sure
>    someone will correct me!

When new data arrives, the Journal subsystem allocates space. If there
is half-filled committed LEB, it may be allocated and its empty space
may be used.

Why half-filled committed LEBs may appear? E.g., if you unmount or do a
sync, we commit everything, including partially filled LEBs.

> ** I have a Perl script that I wrote that helps me automate
>    this and could easily extend my script to do more analysis
>    if I knew what I was looking for.

If it is a general purpose scripts, making it a part of the mtd-utils
could be a good idea.

-- 
Best Regards,
Artem Bityutskiy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120104/8820d9e2/attachment.sig>