public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind@infradead.org>
To: John Smith <john@arrows.demon.co.uk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: UBI: Incorrect initial value for ubi->avail_pebs
Date: Tue, 17 Jul 2007 11:29:03 +0300	[thread overview]
Message-ID: <1184660943.3531.141.camel@sauron> (raw)
In-Reply-To: <Pine.LNX.4.33.0707141836500.19907-100000@arrows.demon.co.uk>

Hi,

On Sat, 2007-07-14 at 19:08 +0100, John Smith wrote:
> I suggest that the initial calculation of ubi->avail_pebs
> is incorrect. But perhaps it is intentionally done this way.
> 
> A number of erase blocks, controlled by CONFIG_MTD_UBI_BEB_RESERVE,
> are reserved for handling bad blocks. The number of actual bad blocks
> are also reserved. I think it would be better if the actual bad blocks
> were taken from the CONFIG_MTD_UBI_BEB_RESERVE allocation.

Yeah, we always reserve this configurable percent of good eraseblocks in
case we have more bad eraseblock in future

> 
> In more detail, during scan time the calculation of ubi->avail_pebs
> goes roughly:
> 
>   /* in attach_by_scanning() */
>   ubi->good_peb_count = ubi->peb_count - ubi->bad_peb_count;
> 
>   /* in ubi_read_volume_table() */
>   ubi->avail_pebs = ubi->good_peb_count;
> 
>   /* in init_volumes() */
>   reserved_pebs =  sum of volume sizes
>   reserved_pebs += size of layout volume
>   ubi->avail_pebs -= reserved_pebs
> 
>   /* in ubi_wl_init_scan() */
>   #define WL_RESERVED_PEBS 1
>   ubi->avail_pebs -= WL_RESERVED_PEBS
> 
>   /* In calculate_reserved() */
>   ubi->beb_rsvd_level = ubi->good_peb_count/100;
>   ubi->beb_rsvd_level *= CONFIG_MTD_UBI_BEB_RESERVE;
> 
>   /* in ubi_eba_init_scan() */
>   ubi->beb_rsvd_pebs = min(ubi->beb_rsvd_level, ubi->avail_pebs)
>   ubi->avail_pebs -= ubi->beb_rsvd_pebs;
> 
> The effect is that existing bad blocks on the device are allocated
> from the budget of blocks for data rather than from the budget of
> blocks for bad blocks.

When a NAND device is shipped it already has some bad eraseblocks. The
number of them is unknown, but they usually guarantee that the number
does not exceed some limit. I just wanted to ensure we always have a
reserved pool which does not depend on the number of already existing
bad eraseblocks. But yes, I can believe that this approach may be too
simple and cause troubles.

> 
> To fix, I suggest that in ubi_read_volume_table() in vtbl.c the
> initial value of ubi->avail_pebs should be set by
> 
>     ubi->avail_pebs = ubi->peb_count ;
> 
> and for consistancy, the beb_rsvd_level should come from
> 
>   ubi->beb_rsvd_level = ubi->peb_count/100;
>   ubi->beb_rsvd_level *= CONFIG_MTD_UBI_BEB_RESERVE;

Well, may be. Provide some arguments against current approach please.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)

      reply	other threads:[~2007-07-17  8:29 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-14 18:08 UBI: Incorrect initial value for ubi->avail_pebs John Smith
2007-07-17  8:29 ` Artem Bityutskiy [this message]

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=1184660943.3531.141.camel@sauron \
    --to=dedekind@infradead.org \
    --cc=john@arrows.demon.co.uk \
    --cc=linux-mtd@lists.infradead.org \
    /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