linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
To: dedekind1@gmail.com
Cc: Richard Genoud <richard.genoud@gmail.com>,
	linux-mtd@lists.infradead.org,
	David Woodhouse <dwmw2@infradead.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] UBI: add minimal amount of reserved erase blocks in Kconfig
Date: Sat, 30 Jun 2012 23:43:03 +0300	[thread overview]
Message-ID: <20120630234303.148c612b@halley> (raw)
In-Reply-To: <1340974064.3070.177.camel@sauron.fi.intel.com>

Hi,

On Fri, 29 Jun 2012 15:47:44 +0300 Artem Bityutskiy <dedekind1@gmail.com> wrote:
> > I'd expect a fixed number of 'beb_rsvd_level' PEBs for a given mtd
> > partition, or more correctly, as Richard suggests, the *sum* of bad PEBs
> > plus the beb reserved PEBs should be constant for a partition - as I
> > do not expect more than a known constant of blocks to go bad during
> > device's (and thus, partition's) lifetime.
> 
> Those days we did not have this "vendor-guaranteed max. bad blocks
> count" thing and I thought that UBI would try to always maintain a pool
> of reserved PEBs.
> 
> Would you send a patch?

Ok. I'll try to fiddle with UBI beb reserved arithmetics.

I thought to make it a gradual change.

First, change the semantics of CONFIG_MTD_UBI_BEB_RESERVE to be the
percent of total number of eraseblocks (instead of total number of
_good_ eraseblocks). And 'reserve' counts for both existing bad PEBs
and those reserved for future bad PEB handling.
Note this would still be % of the blocks in the mtd partition (and as
such, it is very loosely related to the MBB of the device, if at all).

Then, Richard may introduce the MBB parameter to ubiattach, and later
may kill CONFIG_MTD_UBI_BEB_RESERVE (if no longer needed). The
calculations will be according to the new parameter.

What do you say?

On a side note, the new ubiattach parameter should not be called MBB,
but rather a generic "reserved" (or "% reserved").

This is since the MBB is a property of the mtd nand device.
But the ubi user may issue, for the partition attached, a value other
than the device's MBB, according to his storage needs and
risks/securities he is willing to take.

Regards,
Shmulik

  reply	other threads:[~2012-06-30 20:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-25 15:08 [PATCH] UBI: add minimal amount of reserved erase blocks in Kconfig Richard Genoud
2012-06-28 14:39 ` Artem Bityutskiy
2012-06-28 16:07   ` Richard Genoud
2012-06-28 16:22     ` Artem Bityutskiy
2012-06-29  7:17       ` Richard Genoud
2012-06-29 14:10         ` Artem Bityutskiy
2012-06-29 14:57           ` Richard Genoud
2012-06-29 15:07             ` Artem Bityutskiy
2012-06-28 17:53 ` Shmulik Ladkani
2012-06-29 12:47   ` Artem Bityutskiy
2012-06-30 20:43     ` Shmulik Ladkani [this message]
2012-07-02  6:15       ` Richard Genoud
2012-07-03 10:46       ` 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=20120630234303.148c612b@halley \
    --to=shmulik.ladkani@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=richard.genoud@gmail.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;
as well as URLs for NNTP newsgroup(s).