linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: dedekind1@gmail.com
Cc: linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org,
	Richard Weinberger <richard@nod.at>,
	Richard Genoud <richard.genoud@gmail.com>
Subject: Re: [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling
Date: Wed, 18 Jul 2012 22:55:37 +0300	[thread overview]
Message-ID: <20120718225537.38ddbb60@halley> (raw)
In-Reply-To: <1342607317.7530.9.camel@brekeke>

Hi Artem,

On Wed, 18 Jul 2012 13:28:37 +0300 Artem Bityutskiy <dedekind1@gmail.com> wrote:
> The whole thing will become simpler if we first mark the PEB as bad
> unconditionally (because it _is_ bad), then grab the lock and do all the
> re-calculations.

On first glance that would sound the right thing to do.

Actually, when looked at the original code, which does NOT mark the
block bad when 'beb_rsvd_pebs == 0' (instead, does a 'goto out_ro'),
I initially thought "this is SO wrong, the block IS bad, we MUST mark it
bad, what IS the deal here?".
But then I spent more and more time trying to backtrack the reason for
it - and I think I found a reason, quite an improtant one.

Suppose 'beb_rsvd_pebs == 0'.

In the original scheme, it means that there are NO available PEBs at
all. All good PEBs are "assigned" (to user volumes, layout volume, WL
and EBA).

Now, if one of these PEBs goes bad, and you DO mark it bad, and
decrement the good_peb_count, you'll have a shortage of good PEBs - it
will not match the amount of PEBs assigned to the consumers (user
volumes, layout, WL, EBA).
Meaning, next attach would simply fail with a "no enough physical
eraseblocks" message (grep for these in ubi_wl_init and ubi_eba_init).
You won't even be able to attach anymore. Not good.

However, if you DO NOT mark it bad, but instead go into RO mode, you
should be able to later re-attach because the good_peb_count would fit
(no shortage of PEBs).

So going into RO seems a "less worse" solution than marking bad, for
that particular case.

Anyways, I've really invested some thought into this patch, trying to
cover all sorts of esoteric cases.
I think the logic itself is pretty robust, although I would really
appreciate some reassurances on that...

I agree the code does not "read simple" enough, I tried to make the best
simplifying and adding some comments. Let me know if you'd like some
more polish on it.

I saw you submitted a simplified version, I can surely take a look, but
I'm afraid it lacks the proper treatment discussed above (NOT marking
the bad block as bad when beb_rsvd_pebs is zero).

Let me know.

Many thanks,
Shmulik

  parent reply	other threads:[~2012-07-18 19:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04  8:05 [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation Shmulik Ladkani
2012-07-04  8:06 ` [PATCH 1/5] ubi: introduce ubi->bad_peb_limit Shmulik Ladkani
2012-07-18  7:09   ` Artem Bityutskiy
2012-07-18 10:40   ` Artem Bityutskiy
2012-07-19  6:16     ` Shmulik Ladkani
2012-07-30 13:00       ` Artem Bityutskiy
2012-07-04  8:06 ` [PATCH 2/5] ubi: Limit amount of reserved eraseblocks for bad PEB handling Shmulik Ladkani
2012-07-09 10:15   ` Richard Genoud
2012-07-09 11:02     ` Shmulik Ladkani
2012-07-18 10:28   ` Artem Bityutskiy
2012-07-18 11:01     ` Artem Bityutskiy
2012-07-18 19:55     ` Shmulik Ladkani [this message]
2012-07-19  3:35       ` Artem Bityutskiy
2012-07-18 11:40   ` Artem Bityutskiy
2012-07-04  8:06 ` [PATCH 3/5] ubi: kill CONFIG_MTD_UBI_BEB_RESERVE Shmulik Ladkani
2012-07-04  8:06 ` [PATCH 4/5] ubi: trivial: fix comment of ubi_calculate_reserved() Shmulik Ladkani
2012-07-18 10:38   ` Artem Bityutskiy
2012-07-04  8:06 ` [PATCH 5/5] ubi: harmonize the update of ubi->beb_rsvd_pebs Shmulik Ladkani
2012-07-18 11:32   ` Artem Bityutskiy
2012-07-04  8:35 ` [PATCH 0/5] ubi: Fix bad PEBs reserve caclulation Richard Weinberger
2012-07-04 11:33   ` Shmulik Ladkani
2012-07-06 15:27     ` Richard Genoud
2012-07-07  6:14       ` Shmulik Ladkani
2012-07-07  8:32         ` Richard Genoud
2012-07-09  6:58         ` Richard Genoud
2012-07-16 15:33 ` Artem Bityutskiy
2012-07-17  7:23   ` Shmulik Ladkani
2012-07-18  6:54     ` Artem Bityutskiy
2012-07-30 13:56 ` Artem Bityutskiy
2012-07-31  8:19   ` Shmulik Ladkani

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=20120718225537.38ddbb60@halley \
    --to=shmulik.ladkani@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.genoud@gmail.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).