From: Artem Bityutskiy <dedekind1@gmail.com>
To: Steve deRosier <derosier@gmail.com>
Cc: Richard Weinberger <richard@nod.at>,
linux-mtd <linux-mtd@lists.infradead.org>,
Sheng Yong <shengyong1@huawei.com>,
hujianyang <hujianyang@huawei.com>
Subject: Re: [RFC] UBIFS recovery
Date: Fri, 06 Feb 2015 19:26:11 +0200 [thread overview]
Message-ID: <1423243571.8637.579.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <CALupW3CQ3YCvdx_tNeDGVo9cVTcmACyqsMRpr8+P2_4jwGgZMQ@mail.gmail.com>
On Thu, 2015-02-05 at 07:08 -0800, Steve deRosier wrote:
> I hear (and agree with) several valid arguments for a tool in
> userspace. And I'd like to throw my support towards an in-driver
> solution. Flash filesystems are different than on-disk filesystems, in
> particular in their usecase: they're generally both critical and
> exclusive to embedded systems. As such, the entire filesystem might be
> on the corrupted UBIFS, so even if the filesystem is recoverable, if
> we can't mount it and get at the userspace tool, then we're toast.
> Often the kernel itself is stored in a separate read-only partition as
> a blob directly on the flash, and thus the kernel itself would be
> fine. The better UBI & UBIFS can recover to a usable state in-kernel,
> the better off we are I think.
Yes, being able to mount a corrupted FS R/O sounds like a good goal. We
are not speaking of recovery here, just about mounting R/O and providing
access to as much uncorrupted data as we can.
If FS index is not corrupted, this sounds quite doable. If the index is
corrupted, though, this requires full scan and index rebuild. Other wise
we'd mount and show empty file-system.
I can see a potential problem of reading "insane" data from flash (some
circular never ending references, etc) - the driver should be very
careful about those. On the other hand, the driver should be careful
even if we are not talking about corruptions.
Artem.
next prev parent reply other threads:[~2015-02-06 17:26 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-05 9:47 [RFC] UBIFS recovery hujianyang
2015-02-05 13:09 ` shengyong
2015-02-06 17:21 ` Artem Bityutskiy
2015-02-05 15:08 ` Steve deRosier
2015-02-05 23:36 ` Richard Weinberger
2015-02-09 12:08 ` Richard Weinberger
2015-02-06 17:26 ` Artem Bityutskiy [this message]
2015-02-06 17:33 ` Richard Weinberger
2015-02-06 17:40 ` Artem Bityutskiy
2015-02-06 17:43 ` Richard Weinberger
2015-02-09 3:00 ` hujianyang
2015-02-09 7:56 ` Richard Weinberger
2015-02-09 8:26 ` Artem Bityutskiy
2015-02-09 11:04 ` Richard Weinberger
2015-02-09 11:36 ` Artem Bityutskiy
2015-02-09 11:48 ` Richard Weinberger
2015-02-09 2:48 ` hujianyang
2015-02-09 3:09 ` hujianyang
2015-02-06 17:02 ` Artem Bityutskiy
2015-02-09 2:34 ` hujianyang
2015-02-09 7:51 ` Artem Bityutskiy
2015-02-09 7:57 ` Richard Weinberger
2015-02-09 10:38 ` hujianyang
2015-02-09 11:05 ` Richard Weinberger
2015-02-09 11:23 ` hujianyang
2015-02-09 11:18 ` Artem Bityutskiy
2015-02-09 12:02 ` hujianyang
2015-02-09 12:12 ` Ricard Wanderlof
2015-02-09 12:38 ` 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=1423243571.8637.579.camel@sauron.fi.intel.com \
--to=dedekind1@gmail.com \
--cc=derosier@gmail.com \
--cc=hujianyang@huawei.com \
--cc=linux-mtd@lists.infradead.org \
--cc=richard@nod.at \
--cc=shengyong1@huawei.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