From: Artem Bityutskiy <dedekind1@gmail.com>
To: Stefani Seibold <stefani@seibold.net>
Cc: "Kreuzer, Michael \(NSN - DE/Ulm\)" <michael.kreuzer@nsn.com>,
linux-mtd@lists.infradead.org, "Pagliari,
Vivenzio \(NSN - DE/Ulm\)" <vivenzio.pagliari@nsn.com>,
"Matthew L. Creech" <mlcreech@gmail.com>
Subject: Re: ubi_eba_init_scan: cannot reserve enough PEBs
Date: Wed, 01 Sep 2010 18:47:57 +0300 [thread overview]
Message-ID: <1283356077.2209.19.camel@brekeke> (raw)
In-Reply-To: <1283256587.7515.16.camel@wall-e.seibold.net>
Hi,
On Tue, 2010-08-31 at 14:09 +0200, Stefani Seibold wrote:
> Am Sonntag, den 22.08.2010, 18:04 +0300 schrieb Artem Bityutskiy:
> >
> > Yes, but your patch fixes the symptom, unfortunately. It is ok for you
> > to use as a work-around, but I still hope to find the root cause.
> True, but also if we fix the cause, this could happen. Imagine that one
> of the two master LEB will get corrupted, due a flash error or a power
> fail during a write access. Than the system should able to mount this
> damaged file system and restore the lost master LEB.
Firs of all, UBIFS _does_ handle the situation when on master LEB is
corrupted. It is designed for this and this part was tested. _But_ UBIFS
expects that the master LEB is corrupted in _certain way_. If it is
corrupted in an unexpected way - we panic.
To put it differently, we do not handle random corruptions, we handle
only corruptions which _look_ like corruptions caused by power cuts.
In your case you have very strange corruption. We can apply your patch,
problem solved, but will you be 100% comfortable with this? There is a
chance that you have some issues which can later have different
symptoms. I am still interested to find out the real root reason.
I will look at your issue as soon as I have time. I'm currently in
Brazil at the LinuxCon and do not have enough time to look at large
things so far.
> We should try to make UBIFS as robustly as possible and handle all
> possible errors.
Yes. But again, your case is a failure which does not look like a
corruption due to power cuts. In UBIFS we have certain expectations
about how Flash behaves, and we designed UBI/UBIFS around these
expectations. In your the corruption does not fit our expectations. So
we need to understand what happens. Then we can amend UBIFS expectation.
Thus, I think your patch should not be applied to upstream UBIFS
_before_ the reasons of the issue are fully understood.
Lets at least _try_, there is no guarantee we can find out what
happened, but lets try anyway.
> I think it is important to be a bit more defensive and assume the worst
> case.
We do try to be defensive - we refuse mounting if we see that the FS is
screwed in unexpected way. Instead of swallowing corrupted FS and
corrupting it even more - we refuse it. That's very defensive!
As I explained, we recover only if we see that the corruption looks like
the power-cut corruption.
I am actually trying to help you to find the real root cause. Sorry for
my stubbornness, but I really try to help.
--
Best Regards,
Artem Bityutskiy (Битюцкий Артём)
next prev parent reply other threads:[~2010-09-01 15:48 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-22 18:37 ubi_eba_init_scan: cannot reserve enough PEBs Matthew L. Creech
2010-07-26 5:21 ` Artem Bityutskiy
2010-07-26 21:13 ` Matthew L. Creech
2010-07-27 15:12 ` Artem Bityutskiy
2010-07-27 15:21 ` Artem Bityutskiy
2010-07-28 5:46 ` Stefani Seibold
2010-08-22 15:04 ` Artem Bityutskiy
2010-08-31 12:09 ` Stefani Seibold
2010-09-01 15:47 ` Artem Bityutskiy [this message]
2010-09-02 6:47 ` Stefani Seibold
2010-09-02 9:45 ` Artem Bityutskiy
2010-08-22 15:02 ` Artem Bityutskiy
2010-07-27 20:47 ` Matthew L. Creech
2010-07-30 16:12 ` Artem Bityutskiy
2010-07-30 17:51 ` Matthew L. Creech
2010-08-02 4:22 ` Artem Bityutskiy
2010-08-22 18:30 ` Artem Bityutskiy
2010-08-24 22:38 ` Matthew L. Creech
2010-08-25 3:51 ` Artem Bityutskiy
2010-08-31 15:36 ` Matthew L. Creech
2010-09-01 18:57 ` Artem Bityutskiy
2010-09-06 9:17 ` Artem Bityutskiy
2010-09-07 15:59 ` Matthew L. Creech
2010-09-07 17:17 ` Artem Bityutskiy
2010-09-07 17:48 ` Artem Bityutskiy
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=1283356077.2209.19.camel@brekeke \
--to=dedekind1@gmail.com \
--cc=linux-mtd@lists.infradead.org \
--cc=michael.kreuzer@nsn.com \
--cc=mlcreech@gmail.com \
--cc=stefani@seibold.net \
--cc=vivenzio.pagliari@nsn.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 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.