From: hujianyang <hujianyang@huawei.com>
To: Richard Weinberger <richard@nod.at>
Cc: linux-mtd <linux-mtd@lists.infradead.org>,
Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: [PATCH] UBI: add ubi_err() to report the failure of leb read
Date: Tue, 16 Dec 2014 18:34:25 +0800 [thread overview]
Message-ID: <54900AB1.30005@huawei.com> (raw)
In-Reply-To: <549001FC.10008@nod.at>
On 2014/12/16 17:57, Richard Weinberger wrote:
> Then every single embedded vendor will use this flag to keep the broken MTD/UBI/UBIFS setups running
> as long as possible no mater of how corrupted the data is. :-)
> IIRC UBIFS will either mount and work correctly as expected or fail hard.
You are right~!
Maybe we can set filesystem to RO if it is mounted with --force, and
allow users to copy their data to other place.
How about this?
>
>>> You can dump the raw data and inspect the corrupted data.
>>> Maybe you can fix it by hand.
>>
>> Yes, I want a try~! If we have to introduce a new feature or new mount
>> option. So would you like to help me? Do you think it's a valuable
>> work?
>
> I'm not a fan of such a mount option.
> What we really need is a fsck.ubifs and a ubifs dump tool to fix and recover
> broken UBIFS images.
I think it's better, but a bit harder. As I know, my UBIDUMP is far
from what you expect. I should spend more time on it.
After all, I was asked to fix this error. My plan is do something
after an ECC error is detected, not directly breakout to allow
this partition to be mounted. I don't think this solution will be
easily accept by mainline.
However, I'd like to show my work if I succeed.
Thanks~!
Hu
next prev parent reply other threads:[~2014-12-16 10:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-16 7:54 [PATCH] UBI: add ubi_err() to report the failure of leb read hujianyang
2014-12-16 8:02 ` hujianyang
2014-12-16 9:21 ` Richard Weinberger
2014-12-16 9:52 ` hujianyang
2014-12-16 9:57 ` Richard Weinberger
2014-12-16 10:34 ` hujianyang [this message]
2014-12-16 8:58 ` Richard Weinberger
2014-12-16 10:12 ` hujianyang
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=54900AB1.30005@huawei.com \
--to=hujianyang@huawei.com \
--cc=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.