public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Steve deRosier <derosier@gmail.com>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Sheng Yong <shengyong1@huawei.com>,
	hujianyang <hujianyang@huawei.com>
Subject: Re: [RFC] UBIFS recovery
Date: Mon, 09 Feb 2015 10:26:24 +0200	[thread overview]
Message-ID: <1423470384.2573.18.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <54D86819.90803@nod.at>

On Mon, 2015-02-09 at 08:56 +0100, Richard Weinberger wrote:
> Am 09.02.2015 um 04:00 schrieb hujianyang:
> >> This is what fsck.ubifs should to. I was talking about a debugfs.ubifs which
> >> is able to extract files, ask questions, and tell the user what exactly is going
> >> wrong. Like "yes, I can dump you file /foo/bar.dat but rage 5m to 10m maybe be corrupted and the xattrs are gone".
> >>
> > 
> > Er, maybe I know what you mean.
> > 
> > So you think by debugfs.ubifs, we could get wanted file out from a partition
> > without mounting it? and do other things like (?)
> 
> This is the use case of a debugfs. See debugfs.ext2/3/4, etc...
> You can debug (analyze, get files your, etc...) from a broken filesystem
> without mounting it.

Lets consider hypothetical 2 gadgets using UBIFS: R-gadget and H-gadget.

1. R-gadget has UBIFS which refuses to mount whenever there is any
unexpected corruption.
2. H-gadget tries hard to mount in R/O mode and let the rest of the SW
stack have a file-system.

H-gadget is resilient. When things go wrong with the storage, it still
manages to boot, show a dialog explaining that there is a problem, let
users fetch all the important files, and then either reset to factory
defaults, or bring the device to the service point.

R-gadget, on the opposite, just does not boot when there are issues.
Users see nothing on the screen. When they google for "R-gadget does not
boot", they hit some forum discussions, very technical, talking about
some "debugfs", which is very confusing.

The new generation of R-gadget, however, does better job. Unlike the
first generation, shipped under tight TTM requirements, the second
generation gave the vendor a bit more time to polish it. So the vendor
managed to use "debugfs" stuff, and now R-gadget. But unfortunately,
this feature stopped working after first system upgrade, because of a
bug (probably not enough testing). The R-gadgets was asking strange
question about moving some "inodes" from a broken "bud". But the input
did not work, and users anyway had hard time understanding "inodes" and
"buds" (they thought and inoed is some kind of flower).

Anyway, the message is: I'd prefer H-gadget :-)

  reply	other threads:[~2015-02-09  8: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
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 [this message]
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=1423470384.2573.18.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